objectbridge-developers — public list for developer issues

Re: [Objectbridge-developers] XML used in test.ojb.server, etc

[David F. <dw...@la...>]

I downloaded and built the 0.1.41 release without any problems.  However, 
when I run the JUnit
tests it seems to get a number of errors:
...
     [junit] main DELETE FROM Artikel WHERE ( Artikel_Nr = 88888 )
     [junit]     at junit.textui.TestRunner.main(TestRunner.java:94)
     [junit] main SELECT Artikel_Nr , Artikelname , Lieferanten_Nr , 
Kategorie_Nr , Liefereinheit , Einzelpreis , Lagerbestand , 
BestellteEinheiten , MindestBestand , Auslaufartikel FROM Artikel WHERE ( 
Artikel_Nr = 88888 )
     [junit] main INSERT INTO Artikel ( Artikel_Nr , Artikelname , 
Lieferanten_Nr , Kategorie_Nr , Liefereinheit , Einzelpreis , Lagerbestand 
, BestellteEinheiten , MindestBestand , Auslaufartikel ) VALUES ( 88888 , 
NULL , 0 , 0 , NULL , 2.0 , 80 , 0 , 0 , 0 )
     [junit] 180.0
      [junit] main SELECT Artikel_Nr , Artikelname , Lieferanten_Nr , 
Kategorie_Nr , Liefereinheit , Einzelpreis , Lagerbestand , 
BestellteEinheiten , MindestBestand , Auslaufartikel FROM Artikel WHERE ( 
Artikel_Nr = 88888 )
    [junit] java.sql.SQLException: Column: null, not found
     [junit]     at org.enhydra.instantdb.db.SQLProg.execute(SQLProg.java:276)
     [junit] main UPDATE Artikel SET Artikelname = NULL , Lieferanten_Nr = 
0 , Kategorie_Nr = 0 , Liefereinheit = NULL , Einzelpreis = 2.0 , 
Lagerbestand = 90 ,BestellteEinheiten = 0 , MindestBestand = 0 , 
Auslaufartikel = 0 WHERE ( Artikel_Nr = 88888 )
     [junit] main java.sql.SQLException: Column: null, not found
     [junit] Column: null, not found
     [junit]     at 
org.enhydra.instantdb.jdbc.idbPreparedStatement.execute(idbPreparedStatement.java:92)
     [junit]     at 
org.enhydra.instantdb.jdbc.idbPreparedStatement.executeUpdate(idbPreparedStatement.java:71)
     [junit]     at 
ojb.broker.accesslayer.JdbcAccess.executeUpdate(JdbcAccess.java:135)
     [junit]     at 
ojb.broker.PersistenceBrokerImpl.store(PersistenceBrokerImpl.java:471)
     [junit]     at 
ojb.broker.PersistenceBrokerImpl.store(PersistenceBrokerImpl.java:139)
     [junit]     at 
test.ojb.broker.BrokerExamples.testModifications(BrokerExamples.java:130)
     [junit]     at java.lang.reflect.Method.invoke(Native Method)
     [junit]     at junit.framework.TestCase.runTest(TestCase.java:155)
     [junit]     at junit.framework.TestCase.runBare(TestCase.java:129)
     [junit]     at junit.framework.TestResult$1.protect(TestResult.java:100)
     [junit]     at 
junit.framework.TestResult.runProtected(TestResult.java:117)
     [junit]     at junit.framework.TestResult.run(TestResult.java:103)
     [junit]     at junit.framework.TestCase.run(TestCase.java:120)
     [junit]     at junit.framework.TestSuite.run(TestSuite.java:144)
     [junit]     at junit.framework.TestSuite.run(TestSuite.java:144)
     [junit]     at junit.textui.TestRunner.doRun(TestRunner.java:61)
     [junit]     at junit.textui.TestRunner.start(TestRunner.java:242)
     [junit] main DELETE FROM Artikel WHERE ( Artikel_Nr = 88888 )
     [junit]     at junit.textui.TestRunner.main(TestRunner.java:94)
     [junit] main SELECT Artikel_Nr , Artikelname , Lieferanten_Nr , 
Kategorie_Nr , Liefereinheit , Einzelpreis , Lagerbestand , 
BestellteEinheiten , MindestBestand , Auslaufartikel FROM Artikel WHERE ( 
Artikel_Nr = 88888 )


Is this correct?

Also, I can't seem to get the examples to work according to the documentation.
"example server" returns no class found.

Thanks,

-Dave Forslund
At 07:26 PM 1/6/2001 +0100, Thomas Mahler wrote:
>Hi David,
>
>I hope you had a nice christmas and wish you the best for the new year!
>I've used my christmas vacation for relaxing and for working a little on
>improving the PersistenceBroker. It's now quite complete and really
>quite fast.
>I thinks its ready to be used within heavy duty applications.
>
>So once this is mostly finished I'd like to spend more time on the ODMG
>stuff. I hope we find a solution to split the work in order not to
>"stand on each others toes". Maybe I could grasp something that you are
>not currently working on, e.g OQL, or reworking the
>ojb.examples.server.App to work with all the new features...
>
>I've 2 questions regarding your test.ojb.server package:
>1. You seem to use the XERXES parser, I don't get the code compiled
>against the jaxp.jar and parser.jar containing the the JAXP api and the
>standard sun parser.
>Do you need any specific features that only Xerxes provides? If not I'd
>suggest not to use it, as the jar is quite big and we have the comple
>JAXP jar already in our distribution.
>If you think we need xerxes I have no objection but then please check in
>all nesseccary things into CVS.
>2. In class test.ojb.server.StateMachineTest there are references to
>types "TransitionDoesntMatch" and "TestStateUnreachable". I could not
>find those types in CVS?
>
>This did not make any problems with my work on the PersistenceBroker,
>but I had some trouble in getting the new release 0.1.41 built.
>The target "release" depends on the "main-opt" target which tries to
>compile all classes under src.
>I could only build the 0.1.41 release by excluding the test.ojb.server.*
>classes from the main-opt target...
>
>This is no drama but as a general means of quality assurance it's a good
>thing only to build a release when all the sources do compile.
>
>I try to minimize problems with builds and CVS conflicts using the
>following checklist:
>On my development machine (NT):
>1. develop my code with VisualAge 3.5, run all JUnit tests.
>2. run the build junit and build release
>
>On the build machine (Linux)
>3. running cvs update -d to check if someone made changes to files I've
>also been working on
>4. placing my modified files in the according place
>5. running build.sh junit and build.sh release
>6. running cvs commit
>7. if cvs complain about unknown (i.e. newly added files) check them in
>with cvs add
>8. if I moved or deleted some stuff remove it with cvs remove
>9. call cvs commit again and check if there are still some ?
>10. call cvs update -d if I'm still in sync with the repository.
>
>I think using this or a similar scheme we can reduce problems in the
>build process.
>
>I think it would be a good idea to be even more rigid and make the
>"release" target dependend on the "junit" target to express our firm
>believe in Unit testing: "No release without successful regression
>testing".
>
>Best regards,
>
>Thomas
>
>_______________________________________________
>Objectbridge-developers mailing list
>Obj...@li...
>http://lists.sourceforge.net/mailman/listinfo/objectbridge-developers

David W. Forslund                               dw...@la...
Computer and Computational Sciences             http://www.acl.lanl.gov/~dwf
Los Alamos National Laboratory          Los Alamos, NM 87545
505-665-1907                                    FAX: 505-665-4939

[Objectbridge-developers] XML used in test.ojb.server, etc

[Thomas M. <tho...@ho...>]

Hi David,

I hope you had a nice christmas and wish you the best for the new year!
I've used my christmas vacation for relaxing and for working a little on
improving the PersistenceBroker. It's now quite complete and really
quite fast.
I thinks its ready to be used within heavy duty applications.

So once this is mostly finished I'd like to spend more time on the ODMG
stuff. I hope we find a solution to split the work in order not to
"stand on each others toes". Maybe I could grasp something that you are
not currently working on, e.g OQL, or reworking the
ojb.examples.server.App to work with all the new features...

I've 2 questions regarding your test.ojb.server package:
1. You seem to use the XERXES parser, I don't get the code compiled
against the jaxp.jar and parser.jar containing the the JAXP api and the
standard sun parser.
Do you need any specific features that only Xerxes provides? If not I'd
suggest not to use it, as the jar is quite big and we have the comple
JAXP jar already in our distribution.
If you think we need xerxes I have no objection but then please check in
all nesseccary things into CVS. 
2. In class test.ojb.server.StateMachineTest there are references to
types "TransitionDoesntMatch" and "TestStateUnreachable". I could not
find those types in CVS?

This did not make any problems with my work on the PersistenceBroker,
but I had some trouble in getting the new release 0.1.41 built.
The target "release" depends on the "main-opt" target which tries to
compile all classes under src.
I could only build the 0.1.41 release by excluding the test.ojb.server.*
classes from the main-opt target...

This is no drama but as a general means of quality assurance it's a good
thing only to build a release when all the sources do compile.

I try to minimize problems with builds and CVS conflicts using the
following checklist:
On my development machine (NT):
1. develop my code with VisualAge 3.5, run all JUnit tests.
2. run the build junit and build release

On the build machine (Linux)
3. running cvs update -d to check if someone made changes to files I've
also been working on
4. placing my modified files in the according place
5. running build.sh junit and build.sh release
6. running cvs commit
7. if cvs complain about unknown (i.e. newly added files) check them in
with cvs add
8. if I moved or deleted some stuff remove it with cvs remove
9. call cvs commit again and check if there are still some ?
10. call cvs update -d if I'm still in sync with the repository.

I think using this or a similar scheme we can reduce problems in the
build process.

I think it would be a good idea to be even more rigid and make the
"release" target dependend on the "junit" target to express our firm
believe in Unit testing: "No release without successful regression
testing".

Best regards,

Thomas

[Objectbridge-developers] Logging with log4j

[Thomas M. <tho...@ho...>]

Hi Daniele, Hi Rune,

In our last communication you offered to develop a design how to use the
log4j framework for logging purposes within ObJectBridge.
Did you make any progress with this task?

best regards,


Thomas

[Objectbridge-developers] [FYI] forwarding a request regarding ObJectBridge

[Thomas M. <tho...@ho...>]

Hi Simon,

I just received your message forwarded from Michael C. Smith. I don't
know if he answered your questions already, but as one of the original
authors of ObJectBridge I'd like to answer you anyway.

> ---------- Forwarded message ----------
> Date: Fri, 5 Jan 2001 10:32:44 +0000
> Subject: ObjectBridge: do you have an overal design-
> objectives doc?
> From: Simon Brooke <si...@we...>
> To: max...@hu...
> 
> At a brief look this might be a project we'd be interested
> in, we might even be able to put some energy into it. Java
> middleware layer is fundamentally what we do. But reading
> the docs on the SourceForge site doesn't give me enough of
> an idea of what you're trying to achieve.
> 

Oops, you got me. Until now there is no technical documentation apart
from the JavaDoc (which is quite detailed). There is only some "getting
started" stuff. 

> Is the idea that you can store arbitrary, stateful objects
> (including links to other arbitrary objects) into the
> database and later retrieve them and relink them?

The OJB PersistenceBroker allows to store and retrieve (and delete)
arbitrary JAVA objects (including references to other objects) into/from
JDBC compliant RDBMS.
You don't need any special coding to make your business objects
persistence capable apart from a public default constructor. Even
private attributes can be mapped onto DB columns.
The mapping between Objects/attributes and database tables/columns is
completely separated from the business code in a metadata repository.
The repository data is generated from an XML file that describes the
Object/Relational mapping.

I don't know what exactly you mean with "relink them". Are you thinking
about retrieving complex object-nets (say an Order-object with all its
OrderPosition-Objects (1-n) )?
Of course OJB is prepared to retrieve references (1-1 or 1-n)
automatically (by using the foreign-key information of the underlying
tables). So there is no need of relinking your objects programatically.
The PersistenceBroker can be configured to perform or not to perform
such a "cascading" for retrieve-, update-/insert- or delete-operations
on a per class basis (done in the XML repository).
The PersistenceBroker can also be configured to support VirtualProxies (
if you load an Order only lightweight Proxy-instances of all
OrderPositions are instanciated. The "real" OrderPositions are only
loaded on demand).

The PersistenceBroker supports EJB BMP EntityBeans. It has a special
method to retrieve PrimaryKey-Enumerations as needed in EJB
Finder-methods. A performance analysis shows that OJB can improve the
performance of J2EE EntityBean based applications by more than 800% (see
attached report). The perormance gain comes mostly from the usage of an
ObjectCache that reduces DB access and maintains Object-identity. (I.e.
if you perform a lookup with the same PK values twice (even accross
threads) you get one and the same instance and not two instances with
equal attibrutes.)

> 
> Is this intended to be (at least to some degree) database
> portable? We work hard on supporting Postgres, Oracle and
> MS SQL Server, and we know a *lot* about the interesting
> quirks of writing genuinely portable JDBC code.

OJB is intended to work with any JDBC 2.0 compliant RDBMS. There is only
one place in the code where I use a JDBC 2.0 feature
(ResultSet::isLast()). This can easily be modified if you have to work
with JDBC 1.0 drivers.
The generated SQL is VERY simple and should not be problematic on any
RDBMS.
If you find any problems with some RDBMS, we will try to solve them.
It's been successfully tested with MS Access, IBM DB2 UDB and InstantDB.

> 
> Should you be able to stop a complex Java application in
> mid-run, dump it to the database, and later read it back
> from the database (possibly on a different node with a
> different JVM) and just continue the computation where
> you left off?

Yes! You can use the OJB PersistenceBroker to "serialize" your objects
to a RDMBS from one VM. 
Later you can "deserialize" those objects from the RDBMS to the same or
different JVM.
Only effort: you have to describe the Object/Relational mapping for the
Objects (Classes) representing your computational state in a XML file!

There are some working samples in the source distribution that show how
applications using the PersistenceBroker look like. See
http://sourceforge.net/projects/objectbridge.
I'm planning to write a more sophisticated example that can
store/retrieve arbitrary XML DOM trees into/from a RDBMS.

The PersistenceBroker part of OJB is quite stable and should be ready
for usage in production level software. 

> 
> If yes to all these, it *does* look interesting...
> 

The described features are things that most Object/Relational Mappings
can do as well. (e.g TOPLink, Sun JavaBlend, CocoBase, etc.)
One thing that is special about OJB: The ODMG compliant ObjectServer.
The Object Database Management Group (www.odmg.org) defined the ODMG
Java API as a standard API for OO databases. Object oriented databases
like POET, Objectivity or Ozone implement this API. You might say: ODMG
is for OODBMS what JDBC is for RDBMS.

OJB will implement a ODMG 3.0 compliant ObjectServer (with transaction
management, multithreading/multiclient support, configurable Object
locking, OQL support etc.).
This ObjectServer does use the PersistenceBroker as its backend.
The result: the application developer does only have to program against
the ODMG API and not to bother with Object/Relational mappings, SQL,
RDBMS specific things etc.
Benefits:
1. Application code does not contain any O/R, or SQL code, but only
business code. 
   No Object/Relational gap in application code.
2. Application is portable accross RDBMS. It's even possible to run OJB
simultaneously
   against different RDBMS <cool-feature>i.e. store your orders in SQL
Server, 
   keep the OrderPositions in Oracle !</cool-feature>  
3. Database schemata can be modified without touching application code. 
   Only the XML Repository has to be modified accordingly.
4. Migration applications from RDBMS to OODBMS is possible with minimum
effort, as we 
   already use the standard OODB API

These part of OJB is still work in progress, but there is already a
working sample in the source distribution which will give you an
impression how programming against this server will look like.

I hope you got an first impression of our project, even without proper
documentation :-)
If you have any further questions don't hesitate to ask me,

best regards,

Thomas

[Objectbridge-developers] [ANN] objectbridge 0.1.41 released

[Thomas M. <tho...@ho...>]

Hi all and best wishes for the new year!

During my christmas vacation I've been working on a new release.
Here it comes!

Frome the release notes:
ObJectBridge (OJB) is a framework that provides transparent persistence
for Java Objects against relational databases.
It consists of a generic PersistenceBroker and an ODMG 3.0 compliant
transactional ObjectServer as client-interfaces.
It uses an XML based Object/Relational Mapping.

The 0.1.41 release of ObJectBridge includes the following modules:

broker   -- transparent persistence for Java Objects
server   -- ODMG 3.0 compliant Objectserver (work in progress)
examples -- examples demonstrating programming techniques
test     -- JUnit regression tests

new features in 0.1.41:

- Using a pool of Prepared Statements
- introducing different locking stragtegies
- examples are now re-written as JUnit tests

More information is available at
http://sourceforge.net/projects/objectbridge

Copyright (c) 2000, Thomas Mahler, David Dixon-Peugh.


best regards,

Thomas

[Objectbridge-developers] PreparedStatements

[Thomas M. <tho...@ho...>]

Hi all,

I just checked in my current work on Prepared Statements. In fact it is
a extensive refactoring of the ojb.broker.accesslayer and of
PersistenceBrokerImpl.
Now we use PreparedStatements as far as possible. The Prepared
Statements are much faster with most RDBMS and the new mechanism
minimizes the overhead for Object introspection.

For InstantDb the performance gain is not that big :-(

enJoy,

Thomas

RE: [Objectbridge-developers] LockStrategy

[Dixon-Peugh, D. <Dav...@tp...>]

Actually, the QuickMVC project has sort of fallen
by the wayside.  I still have some ideas, but I 
want to get Transactions into OJB first.

And as for the strategies, I think we actually have
RWRepeatableRead and RWUncommittedRead.  I think we
will get Phantom Rows no matter what.  (Until we 
rework the broker.)

David.


-----Original Message-----
From: Thomas Mahler [mailto:tho...@ho...]
Sent: Thursday, December 21, 2000 4:51 AM
To: Dixon-Peugh, David
Cc: 'obj...@li...'
Subject: Re: [Objectbridge-developers] LockStrategy


Hi David,

"Dixon-Peugh, David" wrote:
> 
> I have started some work on the Locking strategies.
> 
> There are now 4 different strategies, located in
> ojb.server.lockstrategy.  These are still pretty
> much in development for now.
> 
> Each one represents the 4 isolation levels as found here:
> http://www.tru64unix.compaq.com/data-access/doc/ODBC/Odbcref/rlock.htm

interesting reference!
> 
> The only ones I have any real faith in are:
>   RWUncommittedReadStrategy
>   RWSerializableStrategy

Same for me! I think the other two may fit well for RDBMS but not so
well for OO-programs.

> 
> (and even those I haven't quite convinced myself that they
> work.)
> 
> Integration of these into the application also hasn't happened.
> 
> I'll let you know when more gets done.
> 

David, what about your Quick-MVC project? Are you making progress?


I'm currently refactoring the Broker to use prepared statements. This
provides another performance boost because PS run much faster on most
RDBMS and the usage of Reflection for building statements can be
minimized.
Coding is finished, I'm doing final testing today and hope to get it
into CVS by tomorrow.

regards,

Thomas

Re: [Objectbridge-developers] LockStrategy

[Thomas M. <tho...@ho...>]

Hi David,

"Dixon-Peugh, David" wrote:
> 
> I have started some work on the Locking strategies.
> 
> There are now 4 different strategies, located in
> ojb.server.lockstrategy.  These are still pretty
> much in development for now.
> 
> Each one represents the 4 isolation levels as found here:
> http://www.tru64unix.compaq.com/data-access/doc/ODBC/Odbcref/rlock.htm

interesting reference!
> 
> The only ones I have any real faith in are:
>   RWUncommittedReadStrategy
>   RWSerializableStrategy

Same for me! I think the other two may fit well for RDBMS but not so
well for OO-programs.

> 
> (and even those I haven't quite convinced myself that they
> work.)
> 
> Integration of these into the application also hasn't happened.
> 
> I'll let you know when more gets done.
> 

David, what about your Quick-MVC project? Are you making progress?


I'm currently refactoring the Broker to use prepared statements. This
provides another performance boost because PS run much faster on most
RDBMS and the usage of Reflection for building statements can be
minimized.
Coding is finished, I'm doing final testing today and hope to get it
into CVS by tomorrow.

regards,

Thomas

[Objectbridge-developers] LockStrategy

[Dixon-Peugh, D. <Dav...@tp...>]

I have started some work on the Locking strategies.  

There are now 4 different strategies, located in
ojb.server.lockstrategy.  These are still pretty
much in development for now.

Each one represents the 4 isolation levels as found here:
http://www.tru64unix.compaq.com/data-access/doc/ODBC/Odbcref/rlock.htm

The only ones I have any real faith in are:
  RWUncommittedReadStrategy
  RWSerializableStrategy

(and even those I haven't quite convinced myself that they
work.)

Integration of these into the application also hasn't happened.

I'll let you know when more gets done.

David.

[Objectbridge-developers] OJB and EJB containers

[Thomas M. <tho...@ho...>]

Hi all,

With my team I made a study on the performance of OJB in the context of
EJB containers.
We developed a BMP solution that uses OJB internally.
We contrasted this a CMP solution with automatically generated SQL code
(using IBM VAP) and with a simple JDBC application not running in a EJB
container.

the results are promising:
BMP/OJB is only 2.78 times slower than the pure JDBC solution running
outside the container and it is more than 8 times (800 % ) faster than
CMP/VAP!

See the attached file for details

regards,


Thomas

[Objectbridge-developers] [ANN] OJB 0.1.30 released

[Thomas M. <tho...@ho...>]

Hi all,

due to maintainance work at sourceforge I had problems in getting my
current snapshot released.
But now it is there!

The 0.1.30 release of ObJectBridge includes the following modules: 
broker -- transparent persistence for Java Objects 
server -- ODMG 3.0 compliant Objectserver (work in progress) 
examples -- examples demonstrating programming techniques 


new features in 0.1.30: 

- Pessimistic Object Locking 
- Object rollback 
- extending Objectserver infrastructure 
- Configurable JDBC connection pooling 
- PersistenceBroker can produce PrimaryKey Enumerations, useful for EJB
finder methods. 
- ANT build scripts 
- Junit regression tests (integrated into build scripts, try
build[.sh|.bat] junit) 

More information is available at
http://sourceforge.net/projects/objectbridge 

enJoy,

Thomas

Re: [Objectbridge-developers] ANT build scripts, CVS

[David Dixon-P. <dp...@mi...>]

If you like Emacs, it will do all your CVS stuff for you.  Very
convienient.

I believe some of the other working environments will do CVS for you
as well.  wincvs.org may have a GUI for Linux too, but I've never used
it.  (I think I prefer the Emacs integration. . .)

David.


Thomas Mahler wrote:

> Hi all,
>
> I got my CVS access working at last.
> I tried to get it running on a Win2000 box for 3 weeks without success.
> Finally I tried it under Linux: worked after 10 minutes !
> Unfortunately I don't have a graphical CVS client at hand, so I have to
> make all cvs actions in a terminal :-#
>
> Do you know of any CVS gui-client fro GNOME or KDE ????
>
> Once I got my CVS client running, I thought: "check in something
> useful":
>
> I took the  ANT build scripts of the CASTOR project as a template for
> OJB.
> The result: a fairly complete build environment.
>
> To see it work, just:
>
> - check out (or update) the module objectbridge from CVS
> - run build[.sh] main
> - run build[.sh] examples
> - run example[.sh] <broker|proxies>
>
> remarks:
> - under Linux use the [.sh] scripts
> - the package ojb.server does not compile yet. this may lead to errors
> during
> build main. Just run "build[.sh] main" twice to get things working!
>
> Comments welcome,
>
> enJoy,
>
> Thomas
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> http://lists.sourceforge.net/mailman/listinfo/objectbridge-developers

[Objectbridge-developers] ANT build scripts, CVS

[Thomas M. <tho...@ho...>]

Hi all,

I got my CVS access working at last.
I tried to get it running on a Win2000 box for 3 weeks without success.
Finally I tried it under Linux: worked after 10 minutes !
Unfortunately I don't have a graphical CVS client at hand, so I have to
make all cvs actions in a terminal :-#

Do you know of any CVS gui-client fro GNOME or KDE ????

Once I got my CVS client running, I thought: "check in something
useful":

I took the  ANT build scripts of the CASTOR project as a template for
OJB.
The result: a fairly complete build environment.

To see it work, just:

- check out (or update) the module objectbridge from CVS
- run build[.sh] main
- run build[.sh] examples
- run example[.sh] <broker|proxies>

remarks: 
- under Linux use the [.sh] scripts
- the package ojb.server does not compile yet. this may lead to errors
during
build main. Just run "build[.sh] main" twice to get things working!

Comments welcome,

enJoy,

Thomas

WG: [Objectbridge-developers] Reader/Writer Locks and other such stuff

[<tho...@it...>]

-----Ursprüngliche Nachricht-----
Von: Thomas Mahler [mailto:tho...@it...]
Gesendet am: Dienstag, 5. Dezember 2000 17:59
An: Dixon-Peugh, David
Betreff: AW: [Objectbridge-developers] Reader/Writer Locks and other
such stuff



> -----Ursprüngliche Nachricht-----
> Von: obj...@li...
> [mailto:obj...@li...]Im Auftrag
> von Dixon-Peugh, David
> Gesendet am: Dienstag, 5. Dezember 2000 15:21
> An: 'Mahler Thomas'; 'obj...@li...'
> Betreff: RE: [Objectbridge-developers] Reader/Writer Locks and other
> such stuff
>
> If we have multiple strategies for locking, then should we have
> different strategies for different classes?
>
> If a class requires a higher level of isolation, it doesn't seem
> like too much trouble to give it to them.  (Perhaps the class is
> suceptable to race conditions?)
>
> -----Original Message-----
> From: obj...@li...
> [mailto:obj...@li...]On Behalf Of
> Mahler Thomas
> Sent: Tuesday, December 05, 2000 4:56 AM
> To: dp...@mi...
> Cc: Dixon-Peugh, David; obj...@li...
> Subject: AW: [Objectbridge-developers] Reader/Writer Locks and other
> such stuff
>

In the EJB specification it's possible to define isolation levels on a per
bean (class) base, to give maximum flexibility to the application developer.
If it's a good idea for EJB it will also be a good idea for OJB ;-)

Thomas

WG: [Objectbridge-developers] Reader/Writer Locks and other such stuff

[<tho...@it...>]

-----Ursprüngliche Nachricht-----
Von: Dixon-Peugh, David [mailto:Dav...@tp...]
Gesendet am: Dienstag, 5. Dezember 2000 17:58
An: 'tho...@it...'
Betreff: RE: [Objectbridge-developers] Reader/Writer Locks and other
such stuff


> ----
> My thoughts are, that if we are storing several objects in the same
> database,
> we want the PersistenceBroker to write them all within the same
> Transaction.
>
> If we use PersistenceBroker as it is now, it will store each object
> independently.
> (Rolling back the database transaction becomes a problem.)

Oops! Thats's a problem that I did not care about before. Here my Idea:
we need control the transactional brace used by PersistenceBroker manually.
So we need new methods:
PersistenceBroker::beginTransaction()
PersistenceBroker::commitTransaction()
PersistenceBroker::abortTransaction()


And in ObjectStateTable we have to modify the method commit() as follows:
public void commit()
{

PeristenceBrokerFactory.createPersistenceBroker().beginTransaction();

	try {
		Iterator i = table.values().iterator();
		while (i.hasNext())
		{
			ObjectModification mod = (ObjectModification)
i.next();
			if (_debug) System.out.println("committing: " +
mod);
			mod.getModificationState().commit(mod);
		}

PeristenceBrokerFactory.createPersistenceBroker().commitTransaction();
	}
	catch (Exception ignored)
	{

PeristenceBrokerFactory.createPersistenceBroker().abortTransaction();
	}
}


So far so good.
But I see 2 more problems here:
1. By design the PersistenceBroker can store different classes in different
databases.
Hence the PersistenceBroker has to manage transactions against (potentially)
multiple RDBMS

-----

If the database driver supports JTS, it isn't a problem to coordinate
everything,
if it doesn't, then we have some interesting failure cases, but we should
come close.

-----

2. The sequence of object commits is an issue!
Imagine the creation of a new order object with dependend OrderPos Objects.
The depend objects might be at position 1, 3, 4, 5, 7 of the
ObjectStateTable.table and the Order Object might be at position 23.
If we sequentially commit the objects from the table, insertion of the
dependen objects will fail if there is referential integrity (RI) defined on
the DB. (you cannot insert a row referencing a row in a another table that
is not yet inserted)
For Delete it's just the other way round: you can delete the order only
after deletion of all dependent orderpos!

-----

I seem to remember somewhere that RI is not enforced until the Commit.  But,
I can't remember where I heard it from, or which database it involves, so
take that with a grain of salt.

-----

Maybe we can ignore this issue at the moment, because we can define our demo
database not to use RI. But as ObJectBridge aims at working with arbitrarily
defined RDMS, it's IMHO a thing that should be addressed.


best regards,


Thomas

-----

What I was thinking about, is using essentially different Object Brokers
depending
on the source.  So, all objects pulled from Sybase are handled by a Sybase
broker,
and all objects pulled from Oracle are handled by an Oracle broker.

It should also be possible to have a single object represented in both
Oracle and
Sybase, which I don't believe can happen at this moment.  (One of my jobs, I
had
to synchronize customer objects throughout an Enterprise, in many different
databases, so I suspect having one object in multiple databases is a real
concern.)

David.

RE: [Objectbridge-developers] Reader/Writer Locks and other such stuff

[Dixon-Peugh, D. <Dav...@tp...>]

If we have multiple strategies for locking, then should we have
different strategies for different classes?

If a class requires a higher level of isolation, it doesn't seem
like too much trouble to give it to them.  (Perhaps the class is
suceptable to race conditions?)

-----Original Message-----
From: obj...@li...
[mailto:obj...@li...]On Behalf Of
Mahler Thomas
Sent: Tuesday, December 05, 2000 4:56 AM
To: dp...@mi...
Cc: Dixon-Peugh, David; obj...@li...
Subject: AW: [Objectbridge-developers] Reader/Writer Locks and other
such stuff



David Dixon-Peugh wrote:
> > >
> > > ojb.server.ReaderWriterLock -
> > >
>
> As for MROW, you end up with an isolation problem.  If you are in
> the process of
> reading an object which is being written to, you end up with the
> wrong data.  (I
> believe
> Oracle calls it dirty reads.)

exactly! But sometimes it's better to have dirty reads than beeing locked
out for a long time.
That's why most DB-Vendors (OODBMS as well as RDBMS) provide the user with a
choice
of several tx isolation levels. Of course your scheme (I guess it is called
TRANSACTION_SERIALIZABLE in java.sql.Connection and EJB) provides a maximum
level of transactional isolation. But this maximum isolation level can
decrease performance of concurrent application by an enormous factor.
Generally speaking there is a tradeoff between tx isolation level and
performance for concurrent applications.

As far as I know ODMG does not specify anything regarding isolation level.

My suggestion:
Let's apply the strategy pattern here. There is an abstract class
AbstractLockingStrategy with concrete implementations. Your implementation
could be called TxSerializableLockingStrategy. This strategy might be used
as default. There could be other implementations (which we don't have to
implement right now):

TxReadUncommitedLockingStrategy : the tx can read uncommited data (i.e.
changed by a different tx that is still in progress. I guess this is
Objectivities MROW)

TxReadCommitedLockingStrategy : data that is being changed by a different tx
cannot be read.

TxRepeatableReadLockingStrategy : the tx cannot change data that is being
read by a different tx.


>
> The problem here though, is that the user of ObJectBridge is
> writing the classes
> themselves.  The code required to keep the reads and writes
> seperate needs to
> happen in the class.  We cannot provide it within ObJectBridge.
>

In the case of your TxSerializableLockingStrategy he user has to handle
LockNotGrantedExceptions that occur due to lockouts from other transactions
that have read or write locks on a given Object.
In the case of MROW the user will have to handle LockNotGrantedExceptions
when a different tx has already a write lock. If the client tries to upgrade
from read- to write lock a different tx might have invalidated the given
Object. Then ojb has to fire an other Exception and the client has to
re-read the object.
So the user has always to handle possible Exceptions thrown from the
TxManager.


> This brings up an interesting flaw, that I can't see any way to
> get around.  We
> cannot
> enforce the READ/WRITE locks on objects that ObJectBridge serves
> up.  So, if you
> have a read lock, you can still modify the object.  (Opens the
> door for many a
> race
> condition for poorly written code.)


That's why I suggest to use implicit locking. Thus the user only has to work
with one single programming concept: tx handling and not to bother with
aquiring locks etc.



>
>
> >
> > >
> > > ojb.server.ObjectTransactionWrapper -
> > >
> > > This class maintains the state of a persistent object at the
> begining and
> > > end of a transaction.  When the wrapper is aborted, the
> persistent fields
> > > of the object are restored to what they were at the begining of the
> > > transaction.
> > >
> >
> > Wow, you are reusing my ClassDescriptor / FieldDescriptor
> stuff! looks great.
> >
> > >
> > > ojb.server.TransactionImpl -
> > >
> > > This class has been modified to use the Reader/Writer locks
> as apropriate.
> > > It has also been modified to build ObjectTransactionWrapper around all
> > > objects
> > > that a WRITE lock is acquired on.
> >
> > When I get your code right, you want the user to explicitely
> aquire read and
> > write locks ?
> > My suggestion: use TransactionImpl::markModified() to aquire a
> write lock
> > implicitely. Thus the user has not to care about locking but
> can just call a
> > setter. Of course the possible LockNotGrantedExceptions have to
> be reached
> > back to the user.
> > What do you think?
> >
> > Getting implicit read locks maybe not so easy? Perhaps we have
> to place a
> > Transaction::lock(ObjectToRead, Transaction.READ) in all getters?
> >
>
> I would like the user to explicitely get WRITE locks.  READ locks
> can be granted
> when we serve up the object.  (Maybe we can serve up the READ locks in the
> implementation of DList or such.)
>
> From what I've seen of the ODMG spec, we need to provide explicit locking
> capabilities anyways, so getting a WRITE lock like that isn't
> such a big deal.
>

I have no objections regarding getting manual locks. But if you have an
object locked with a read lock and you call a setter method it is obvious
that you implicitely intend to get a write lock on the object. As we call
markModified() in each setter it would be a courtesy for our user to acquire
the write-lock form him if he did not acquired it already.


>
> >
> > >
> > >
> > > It has been modified to have ObjectTransactionWrapper
> commit/abort where
> > > apropriate.
> >
> > Your ObjectTransactionWrapper::comit() is still empty, do you
> want to reuse my
> > ObjectModification / ModificationState stuff or do you have
> other ideas for
> > triggering the adequate PersistenceBroker calls?
> >
>
> At this point, ObjectTransactionWrapper is only responsible for
> the in memory
> version
> of the object.  The Object is in its commited form when the transaction is
> commited,
> hense no code.
>
> I'm not sure if putting the storage stuff into the
> ObjectTransactionWrapper is
> necessarily
> a good idea.  Ultimately, all objects from the same database need
> to be committed
> within
> the same database transaction, and it seems unlilkely that the
> ObjectTransactionWrapper
> can identify which transaction to commit it in without some big ugly hack.
>

This is clear to me. But I was asking because you removed all calls to
PersistenceBroker.store(...)

I am definitely open to suggestions on how we can merge these operations
though.

I'm not sure, but why not call PersistenceBroker.store() from within
TransactionImpl.commit() immediately after your
ObjectTransactionWrapper.commit() ?

best regards ,

Thomas


_______________________________________________
Objectbridge-developers mailing list
Obj...@li...
http://lists.sourceforge.net/mailman/listinfo/objectbridge-developers

RE: [Objectbridge-developers] Reader/Writer Locks and other such stuff

[Dixon-Peugh, D. <Dav...@tp...>]

-----
 
  These are my Comments below. . .

-----

-----Original Message-----
From: tho...@it... [mailto:tho...@it...]
Sent: Tuesday, December 05, 2000 4:56 AM
To: dp...@mi...
Cc: Dixon-Peugh, David; obj...@li...
Subject: AW: [Objectbridge-developers] Reader/Writer Locks and other
such stuff



David Dixon-Peugh wrote:
> > >
> > > ojb.server.ReaderWriterLock -
> > >
>
> As for MROW, you end up with an isolation problem.  If you are in
> the process of
> reading an object which is being written to, you end up with the
> wrong data.  (I
> believe
> Oracle calls it dirty reads.)

exactly! But sometimes it's better to have dirty reads than beeing locked
out for a long time.
That's why most DB-Vendors (OODBMS as well as RDBMS) provide the user with a
choice
of several tx isolation levels. Of course your scheme (I guess it is called
TRANSACTION_SERIALIZABLE in java.sql.Connection and EJB) provides a maximum
level of transactional isolation. But this maximum isolation level can
decrease performance of concurrent application by an enormous factor.
Generally speaking there is a tradeoff between tx isolation level and
performance for concurrent applications.

As far as I know ODMG does not specify anything regarding isolation level.

My suggestion:
Let's apply the strategy pattern here. There is an abstract class
AbstractLockingStrategy with concrete implementations. Your implementation
could be called TxSerializableLockingStrategy. This strategy might be used
as default. There could be other implementations (which we don't have to
implement right now):

TxReadUncommitedLockingStrategy : the tx can read uncommited data (i.e.
changed by a different tx that is still in progress. I guess this is
Objectivities MROW)

TxReadCommitedLockingStrategy : data that is being changed by a different tx
cannot be read.

TxRepeatableReadLockingStrategy : the tx cannot change data that is being
read by a different tx.

-----

Sounds good, lets give it a try. . .

-----
>
> The problem here though, is that the user of ObJectBridge is
> writing the classes
> themselves.  The code required to keep the reads and writes
> seperate needs to
> happen in the class.  We cannot provide it within ObJectBridge.
>

In the case of your TxSerializableLockingStrategy he user has to handle
LockNotGrantedExceptions that occur due to lockouts from other transactions
that have read or write locks on a given Object.
In the case of MROW the user will have to handle LockNotGrantedExceptions
when a different tx has already a write lock. If the client tries to upgrade
from read- to write lock a different tx might have invalidated the given
Object. Then ojb has to fire an other Exception and the client has to
re-read the object.
So the user has always to handle possible Exceptions thrown from the
TxManager.


> This brings up an interesting flaw, that I can't see any way to
> get around.  We
> cannot
> enforce the READ/WRITE locks on objects that ObJectBridge serves
> up.  So, if you
> have a read lock, you can still modify the object.  (Opens the
> door for many a
> race
> condition for poorly written code.)


That's why I suggest to use implicit locking. Thus the user only has to work
with one single programming concept: tx handling and not to bother with
aquiring locks etc.

>
>
> >
> > >
> > > ojb.server.ObjectTransactionWrapper -
> > >
> > > This class maintains the state of a persistent object at the
> begining and
> > > end of a transaction.  When the wrapper is aborted, the
> persistent fields
> > > of the object are restored to what they were at the begining of the
> > > transaction.
> > >
> >
> > Wow, you are reusing my ClassDescriptor / FieldDescriptor
> stuff! looks great.
> >
> > >
> > > ojb.server.TransactionImpl -
> > >
> > > This class has been modified to use the Reader/Writer locks
> as apropriate.
> > > It has also been modified to build ObjectTransactionWrapper around all
> > > objects
> > > that a WRITE lock is acquired on.
> >
> > When I get your code right, you want the user to explicitely
> aquire read and
> > write locks ?
> > My suggestion: use TransactionImpl::markModified() to aquire a
> write lock
> > implicitely. Thus the user has not to care about locking but
> can just call a
> > setter. Of course the possible LockNotGrantedExceptions have to
> be reached
> > back to the user.
> > What do you think?
> >
> > Getting implicit read locks maybe not so easy? Perhaps we have
> to place a
> > Transaction::lock(ObjectToRead, Transaction.READ) in all getters?
> >
>
> I would like the user to explicitely get WRITE locks.  READ locks
> can be granted
> when we serve up the object.  (Maybe we can serve up the READ locks in the
> implementation of DList or such.)
>
> From what I've seen of the ODMG spec, we need to provide explicit locking
> capabilities anyways, so getting a WRITE lock like that isn't
> such a big deal.
>

I have no objections regarding getting manual locks. But if you have an
object locked with a read lock and you call a setter method it is obvious
that you implicitely intend to get a write lock on the object. As we call
markModified() in each setter it would be a courtesy for our user to acquire
the write-lock form him if he did not acquired it already.


-----

The question becomes how do we know when to lock it?  How is calling
"markModified"
any different from acquiring a WRITE lock?

-----

>
> >
> > >
> > >
> > > It has been modified to have ObjectTransactionWrapper
> commit/abort where
> > > apropriate.
> >
> > Your ObjectTransactionWrapper::comit() is still empty, do you
> want to reuse my
> > ObjectModification / ModificationState stuff or do you have
> other ideas for
> > triggering the adequate PersistenceBroker calls?
> >
>
> At this point, ObjectTransactionWrapper is only responsible for
> the in memory
> version
> of the object.  The Object is in its commited form when the transaction is
> commited,
> hense no code.
>
> I'm not sure if putting the storage stuff into the
> ObjectTransactionWrapper is
> necessarily
> a good idea.  Ultimately, all objects from the same database need
> to be committed
> within
> the same database transaction, and it seems unlilkely that the
> ObjectTransactionWrapper
> can identify which transaction to commit it in without some big ugly hack.
>

This is clear to me. But I was asking because you removed all calls to
PersistenceBroker.store(...)

I am definitely open to suggestions on how we can merge these operations
though.

I'm not sure, but why not call PersistenceBroker.store() from within
TransactionImpl.commit() immediately after your
ObjectTransactionWrapper.commit() ?

----
My thoughts are, that if we are storing several objects in the same
database,
we want the PersistenceBroker to write them all within the same Transaction.

If we use PersistenceBroker as it is now, it will store each object
independently.
(Rolling back the database transaction becomes a problem.)

----
best regards ,

Thomas

----

Thanks,

David.

AW: [Objectbridge-developers] Reader/Writer Locks and other such stuff

[<tho...@it...>]

David Dixon-Peugh wrote:
> > >
> > > ojb.server.ReaderWriterLock -
> > >
>
> As for MROW, you end up with an isolation problem.  If you are in
> the process of
> reading an object which is being written to, you end up with the
> wrong data.  (I
> believe
> Oracle calls it dirty reads.)

exactly! But sometimes it's better to have dirty reads than beeing locked
out for a long time.
That's why most DB-Vendors (OODBMS as well as RDBMS) provide the user with a
choice
of several tx isolation levels. Of course your scheme (I guess it is called
TRANSACTION_SERIALIZABLE in java.sql.Connection and EJB) provides a maximum
level of transactional isolation. But this maximum isolation level can
decrease performance of concurrent application by an enormous factor.
Generally speaking there is a tradeoff between tx isolation level and
performance for concurrent applications.

As far as I know ODMG does not specify anything regarding isolation level.

My suggestion:
Let’s apply the strategy pattern here. There is an abstract class
AbstractLockingStrategy with concrete implementations. Your implementation
could be called TxSerializableLockingStrategy. This strategy might be used
as default. There could be other implementations (which we don’t have to
implement right now):

TxReadUncommitedLockingStrategy : the tx can read uncommited data (i.e.
changed by a different tx that is still in progress. I guess this is
Objectivities MROW)

TxReadCommitedLockingStrategy : data that is being changed by a different tx
cannot be read.

TxRepeatableReadLockingStrategy : the tx cannot change data that is being
read by a different tx.


>
> The problem here though, is that the user of ObJectBridge is
> writing the classes
> themselves.  The code required to keep the reads and writes
> seperate needs to
> happen in the class.  We cannot provide it within ObJectBridge.
>

In the case of your TxSerializableLockingStrategy he user has to handle
LockNotGrantedExceptions that occur due to lockouts from other transactions
that have read or write locks on a given Object.
In the case of MROW the user will have to handle LockNotGrantedExceptions
when a different tx has already a write lock. If the client tries to upgrade
from read- to write lock a different tx might have invalidated the given
Object. Then ojb has to fire an other Exception and the client has to
re-read the object.
So the user has always to handle possible Exceptions thrown from the
TxManager.


> This brings up an interesting flaw, that I can't see any way to
> get around.  We
> cannot
> enforce the READ/WRITE locks on objects that ObJectBridge serves
> up.  So, if you
> have a read lock, you can still modify the object.  (Opens the
> door for many a
> race
> condition for poorly written code.)


That’s why I suggest to use implicit locking. Thus the user only has to work
with one single programming concept: tx handling and not to bother with
aquiring locks etc.



>
>
> >
> > >
> > > ojb.server.ObjectTransactionWrapper -
> > >
> > > This class maintains the state of a persistent object at the
> begining and
> > > end of a transaction.  When the wrapper is aborted, the
> persistent fields
> > > of the object are restored to what they were at the begining of the
> > > transaction.
> > >
> >
> > Wow, you are reusing my ClassDescriptor / FieldDescriptor
> stuff! looks great.
> >
> > >
> > > ojb.server.TransactionImpl -
> > >
> > > This class has been modified to use the Reader/Writer locks
> as apropriate.
> > > It has also been modified to build ObjectTransactionWrapper around all
> > > objects
> > > that a WRITE lock is acquired on.
> >
> > When I get your code right, you want the user to explicitely
> aquire read and
> > write locks ?
> > My suggestion: use TransactionImpl::markModified() to aquire a
> write lock
> > implicitely. Thus the user has not to care about locking but
> can just call a
> > setter. Of course the possible LockNotGrantedExceptions have to
> be reached
> > back to the user.
> > What do you think?
> >
> > Getting implicit read locks maybe not so easy? Perhaps we have
> to place a
> > Transaction::lock(ObjectToRead, Transaction.READ) in all getters?
> >
>
> I would like the user to explicitely get WRITE locks.  READ locks
> can be granted
> when we serve up the object.  (Maybe we can serve up the READ locks in the
> implementation of DList or such.)
>
> From what I've seen of the ODMG spec, we need to provide explicit locking
> capabilities anyways, so getting a WRITE lock like that isn't
> such a big deal.
>

I have no objections regarding getting manual locks. But if you have an
object locked with a read lock and you call a setter method it is obvious
that you implicitely intend to get a write lock on the object. As we call
markModified() in each setter it would be a courtesy for our user to acquire
the write-lock form him if he did not acquired it already.


>
> >
> > >
> > >
> > > It has been modified to have ObjectTransactionWrapper
> commit/abort where
> > > apropriate.
> >
> > Your ObjectTransactionWrapper::comit() is still empty, do you
> want to reuse my
> > ObjectModification / ModificationState stuff or do you have
> other ideas for
> > triggering the adequate PersistenceBroker calls?
> >
>
> At this point, ObjectTransactionWrapper is only responsible for
> the in memory
> version
> of the object.  The Object is in its commited form when the transaction is
> commited,
> hense no code.
>
> I'm not sure if putting the storage stuff into the
> ObjectTransactionWrapper is
> necessarily
> a good idea.  Ultimately, all objects from the same database need
> to be committed
> within
> the same database transaction, and it seems unlilkely that the
> ObjectTransactionWrapper
> can identify which transaction to commit it in without some big ugly hack.
>

This is clear to me. But I was asking because you removed all calls to
PersistenceBroker.store(…)

I am definitely open to suggestions on how we can merge these operations
though.

I’m not sure, but why not call PersistenceBroker.store() from within
TransactionImpl.commit() immediately after your
ObjectTransactionWrapper.commit() ?

best regards ,

Thomas

AW: [Objectbridge-developers] Unit Testing and Build Scripts

[<tho...@it...>]

> -----Ursprüngliche Nachricht-----
> Von: obj...@li...
> [mailto:obj...@li...]Im Auftrag
> von Dixon-Peugh, David
> Gesendet am: Montag, 4. Dezember 2000 22:17
> An: 'obj...@li...'
> Betreff: [Objectbridge-developers] Unit Testing and Build Scripts
>
>
> I started to look at JUnit as a means of testing some of
> the ObJectBridge code.  I think this could be very helpful
> in at least validating what we do.  (http://www.junit.org)

I already set up a Task for this. See:
http://sourceforge.net/pm/task.php?func=detailtask&project_task_id=21120&gro
up_id=13647&group_project_id=5391

JUnit is really an excellent tool. But it is not easy to achieve a good
test-coverage if you do not use the "test a little -- code a little"-cycle
right from the start. It's at least as difficult as starting documentation
of a project after you've finished coding.

>
> I'm also looking at building an Ant build script to handle
> the build of the application.  I've done it once before,
> and I think that ant would probably be a better choice than
> the scripts we currently have.  (They don't work quite right
> on UNIX.)

I also prefer using ANT. See Task:
http://sourceforge.net/pm/task.php?func=detailtask&project_task_id=21310&gro
up_id=13647&group_project_id=5389

regards, Thomas

[Objectbridge-developers] Unit Testing and Build Scripts

[Dixon-Peugh, D. <Dav...@tp...>]

I started to look at JUnit as a means of testing some of
the ObJectBridge code.  I think this could be very helpful
in at least validating what we do.  (http://www.junit.org)

I'm also looking at building an Ant build script to handle
the build of the application.  I've done it once before,
and I think that ant would probably be a better choice than
the scripts we currently have.  (They don't work quite right
on UNIX.)

David.

Re: [Objectbridge-developers] Reader/Writer Locks and other such stuff

[David Dixon-P. <dp...@mi...>]

Thomas Mahler wrote:

> Hi David!
>
> "Dixon-Peugh, David" wrote:
>
> > Good evening.
> >
> > I've been doing some work on ObJectBridge, and have made some
> > further progress.
>
> Thanks for all your efforts!
>
> > First a note on CVS.
> >
> > When I tried to connect to CVS from home, I was unable to get
> > to the "ojb" directory of ObJectBridge.  I dropped some work into
> > the "objectbridge" directory.  I've moved just about everything
> > that has been updated to "objectbridge" from "ojb" (as I can
> > get to both at work, but only one at home.)
> >
>
> David, I still have trouble with my WinCVS / SSH configuration. Reading stuff
> from the repository to my local disk works fine, but I just don't manage to
> get write access. Something with my SSH configuration must be wrong. I spend
> several day's reading manuals, downloading sevral ssh implementations --
> without success.Now I don't have any ideas what could be wrong. Can you help
> me a little ?
> Do you work with WinCVS / SSH ?
> I have finished some improvements to the PersistenceBroker. But since I can't
> check my stuff in. I think distributing another tarball is not an option,
> since we are working under CVS conditions now. So I have to stick to the
> rules...
>

I do work withWinCVS / SSH a little bit.  But I just futzed with it and it
worked.
No idea why.  I don't really have any insights as to why mine works and yours
doesn't.

>
> >
> > Now, as for the changes:
> >
> > ojb.server.ReaderWriterLock -
> >
> > This class implements a ReaderWriterLock on an object.  Unfortunately,
> > we cannot enforce this lock (its up to the user to do that.)  There are
> > basically a couple of APIs:
> >         read( Trans )
> >         write( Trans )
> >         upgrade( Trans )
> >         release( Trans )
> >
> > Right now, the locks are maintained in the TransactionImpl (wrong place,
> > should probably be in a LockManager or such.)
> >
>
> I had a look at your code and it looks quite promising! Do you have
> experiences with systems using this multiple readers or exactly one writer
> scheme ?
> I had the chance to work with Objectivity DB they have a interesting
> alternative strategy:
> Multiple Readers and possibly One Writer (they call it MROW). I.E. you can get
> a write lock even when there are some readers yet. And you can obtain a read
> lock when another transaction has a write lock.
>
> This strategy reduces locking situations when using long transaction. But it
> has a large disadvantage: when you want to upgrade a lock from read to write
> another tx might have modified the object (with or without a commit). These
> lock invalidations are signalled via exceptions to the client and have to
> dealed with in the user code.
> So maybe it is the best choice to use your exclusive strategy (is there a
> special name for it?) until we have more experiences with the system.
>
> You are right we need a separate LockManager class.

Actually, I don't have much experience using Reader/Writer.  I just investigated/

coded that class.

As for MROW, you end up with an isolation problem.  If you are in the process of
reading an object which is being written to, you end up with the wrong data.  (I
believe
Oracle calls it dirty reads.)

The problem here though, is that the user of ObJectBridge is writing the classes
themselves.  The code required to keep the reads and writes seperate needs to
happen in the class.  We cannot provide it within ObJectBridge.

This brings up an interesting flaw, that I can't see any way to get around.  We
cannot
enforce the READ/WRITE locks on objects that ObJectBridge serves up.  So, if you
have a read lock, you can still modify the object.  (Opens the door for many a
race
condition for poorly written code.)


>
> >
> > ojb.server.ObjectTransactionWrapper -
> >
> > This class maintains the state of a persistent object at the begining and
> > end of a transaction.  When the wrapper is aborted, the persistent fields
> > of the object are restored to what they were at the begining of the
> > transaction.
> >
>
> Wow, you are reusing my ClassDescriptor / FieldDescriptor stuff! looks great.
>
> >
> > ojb.server.TransactionImpl -
> >
> > This class has been modified to use the Reader/Writer locks as apropriate.
> > It has also been modified to build ObjectTransactionWrapper around all
> > objects
> > that a WRITE lock is acquired on.
>
> When I get your code right, you want the user to explicitely aquire read and
> write locks ?
> My suggestion: use TransactionImpl::markModified() to aquire a write lock
> implicitely. Thus the user has not to care about locking but can just call a
> setter. Of course the possible LockNotGrantedExceptions have to be reached
> back to the user.
> What do you think?
>
> Getting implicit read locks maybe not so easy? Perhaps we have to place a
> Transaction::lock(ObjectToRead, Transaction.READ) in all getters?
>

I would like the user to explicitely get WRITE locks.  READ locks can be granted
when we serve up the object.  (Maybe we can serve up the READ locks in the
implementation of DList or such.)

From what I've seen of the ODMG spec, we need to provide explicit locking
capabilities anyways, so getting a WRITE lock like that isn't such a big deal.


>
> >
> >
> > It has been modified to have ObjectTransactionWrapper commit/abort where
> > apropriate.
>
> Your ObjectTransactionWrapper::comit() is still empty, do you want to reuse my
> ObjectModification / ModificationState stuff or do you have other ideas for
> triggering the adequate PersistenceBroker calls?
>

At this point, ObjectTransactionWrapper is only responsible for the in memory
version
of the object.  The Object is in its commited form when the transaction is
commited,
hense no code.

I'm not sure if putting the storage stuff into the ObjectTransactionWrapper is
necessarily
a good idea.  Ultimately, all objects from the same database need to be committed
within
the same database transaction, and it seems unlilkely that the
ObjectTransactionWrapper
can identify which transaction to commit it in without some big ugly hack.

I am definitely open to suggestions on how we can merge these operations though.

>
> >
> >
> > ojb.server.TransactionAware -
> >
> > This is an interface that the end-user can implement.  With the
> > TransactionAware iface,
> > you can kill a transaction which involves your object.  You can also clean
> > up in
> > the event of an abort.
> >
>
> Good to give usere the ability to interact with the Transaction mechanism.
>
> >
> > Share and Enjoy!
> >
> > David.
>
> All your code looks quite promising!
>
> I've been silently working on improvements of the PersistenceBroker in the
> last 2 weeks. I introduced configurable Connection pooling, which gave a real
> performance boost.
> I was also experimenting with using the PersistenceBroker in J2EE Entitiy
> Beans (Bean Managed Persitence right now). These experiments produced
> interesting results: using BMP with ObJectBridge as O/R layer increased
> performance by a factor 2 - 5 over CMP (using IBM WebSphere and IBMs VAP
> Persistence layer).
> These positive results have 3 main reasons:
> - The ObjectCache
> - Smart Updating techniques using ObjectModifications
> - I extended the PersistenceBroker interface by
> getPkEnumerationByConstraints(...) which is quite helpful in building
> ejbFindByXXX methods.
> I will repeat my tests with improved diagnostics and will inform you about the
> results.
>
> Do you know JDO (Java Data Objects), the new SUN spec for Java-persistence.
> Last weekend I heared of it for the first time. In some respects it seems to
> be a succecessor to ODMG.
> I also discovered CASTOR, and open source project by EXOLAB. They have
> implemented JDO. quite interesting approach. There are some similarities to
> ObJectBridge, but their code is much more complex than ours and they are
> already at release 0.8.9 !
>
> They have a lot of interesting concepts (E.g. an OQL implementation... which
> could be helpful for us)
>
> best regards,
>
> Thomas
>
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> http://lists.sourceforge.net/mailman/listinfo/objectbridge-developers

As for CASTOR, I think I ran across them once, but didn't look much further.
This is also the
first I've heard of JDO.

I'll take a look at each of them, and see what I can steal for the transaction
implementation.
(Or even the OQL implementation, which I would really like to give a shot, but
don't have a
starting point yet.)

Thanks,

David

[Objectbridge-developers] related opensource projects

[Thomas M. <tho...@ho...>]

Here are some links to related projects:
http://castor.exolab.org
VERY interesting! they have a lot of excellent concepts and high quality
code. main concepts: SQL, XML and LDAP Persistence. JDO implementation,
OQL implementation, runtime compilation of Descriptor classes, Service
provider for EJB Container Managed Persistence, etc...

IMHO JDO (see
http://java.sun.com/aboutJava/communityprocess/jsr/jsr_012_dataobj.html
or http://java.sun.com/products/jdbc/related.html ) will have an
enormous impact on the development of EJB servers and persistence
frameworks. I suppose it will gain much more momentum than ODMG.
Once we have implemented ODMG it won't be difficult to build an JDO
wrapper. But we should start studying the JDO concepts right now, We
could also start with an JDO implementation right now and build an
architecture with pluggable APIs.

What do you think?

http://sourceforge.net/projects/osage
very active project on sourceforge. SQL persistence, XML mapping from
CASTOR, does not cover all ObJectBridge features (ObjectCache,
Transaction management, ODMG)

http://sourceforge.net/projects/dbobjects
more concerned with low level aspects of O/R mapping. possibly a source
for optimization strategies

http://sourceforge.net/projects/fodmg
an upcoming project that aims at a free ODMG implementation (againt
RDBMS I assume) for C, Perl, Python and JAVA. In my eyes the Java part
is currently being done by OJB.

regards,

Thomas

Re: [Objectbridge-developers] Reader/Writer Locks and other such stuff

[Thomas M. <tho...@ho...>]

Hi David!

"Dixon-Peugh, David" wrote:

> Good evening.
>
> I've been doing some work on ObJectBridge, and have made some
> further progress.

Thanks for all your efforts!

> First a note on CVS.
>
> When I tried to connect to CVS from home, I was unable to get
> to the "ojb" directory of ObJectBridge.  I dropped some work into
> the "objectbridge" directory.  I've moved just about everything
> that has been updated to "objectbridge" from "ojb" (as I can
> get to both at work, but only one at home.)
>

David, I still have trouble with my WinCVS / SSH configuration. Reading stuff
from the repository to my local disk works fine, but I just don't manage to
get write access. Something with my SSH configuration must be wrong. I spend
several day's reading manuals, downloading sevral ssh implementations --
without success.Now I don't have any ideas what could be wrong. Can you help
me a little ?
Do you work with WinCVS / SSH ?
I have finished some improvements to the PersistenceBroker. But since I can't
check my stuff in. I think distributing another tarball is not an option,
since we are working under CVS conditions now. So I have to stick to the
rules...

>
> Now, as for the changes:
>
> ojb.server.ReaderWriterLock -
>
> This class implements a ReaderWriterLock on an object.  Unfortunately,
> we cannot enforce this lock (its up to the user to do that.)  There are
> basically a couple of APIs:
>         read( Trans )
>         write( Trans )
>         upgrade( Trans )
>         release( Trans )
>
> Right now, the locks are maintained in the TransactionImpl (wrong place,
> should probably be in a LockManager or such.)
>

I had a look at your code and it looks quite promising! Do you have
experiences with systems using this multiple readers or exactly one writer
scheme ?
I had the chance to work with Objectivity DB they have a interesting
alternative strategy:
Multiple Readers and possibly One Writer (they call it MROW). I.E. you can get
a write lock even when there are some readers yet. And you can obtain a read
lock when another transaction has a write lock.

This strategy reduces locking situations when using long transaction. But it
has a large disadvantage: when you want to upgrade a lock from read to write
another tx might have modified the object (with or without a commit). These
lock invalidations are signalled via exceptions to the client and have to
dealed with in the user code.
So maybe it is the best choice to use your exclusive strategy (is there a
special name for it?) until we have more experiences with the system.

You are right we need a separate LockManager class.

>
> ojb.server.ObjectTransactionWrapper -
>
> This class maintains the state of a persistent object at the begining and
> end of a transaction.  When the wrapper is aborted, the persistent fields
> of the object are restored to what they were at the begining of the
> transaction.
>

Wow, you are reusing my ClassDescriptor / FieldDescriptor stuff! looks great.

>
> ojb.server.TransactionImpl -
>
> This class has been modified to use the Reader/Writer locks as apropriate.
> It has also been modified to build ObjectTransactionWrapper around all
> objects
> that a WRITE lock is acquired on.

When I get your code right, you want the user to explicitely aquire read and
write locks ?
My suggestion: use TransactionImpl::markModified() to aquire a write lock
implicitely. Thus the user has not to care about locking but can just call a
setter. Of course the possible LockNotGrantedExceptions have to be reached
back to the user.
What do you think?

Getting implicit read locks maybe not so easy? Perhaps we have to place a
Transaction::lock(ObjectToRead, Transaction.READ) in all getters?

>
>
> It has been modified to have ObjectTransactionWrapper commit/abort where
> apropriate.

Your ObjectTransactionWrapper::comit() is still empty, do you want to reuse my
ObjectModification / ModificationState stuff or do you have other ideas for
triggering the adequate PersistenceBroker calls?

>
>
> ojb.server.TransactionAware -
>
> This is an interface that the end-user can implement.  With the
> TransactionAware iface,
> you can kill a transaction which involves your object.  You can also clean
> up in
> the event of an abort.
>

Good to give usere the ability to interact with the Transaction mechanism.

>
> Share and Enjoy!
>
> David.

All your code looks quite promising!

I've been silently working on improvements of the PersistenceBroker in the
last 2 weeks. I introduced configurable Connection pooling, which gave a real
performance boost.
I was also experimenting with using the PersistenceBroker in J2EE Entitiy
Beans (Bean Managed Persitence right now). These experiments produced
interesting results: using BMP with ObJectBridge as O/R layer increased
performance by a factor 2 - 5 over CMP (using IBM WebSphere and IBMs VAP
Persistence layer).
These positive results have 3 main reasons:
- The ObjectCache
- Smart Updating techniques using ObjectModifications
- I extended the PersistenceBroker interface by
getPkEnumerationByConstraints(...) which is quite helpful in building
ejbFindByXXX methods.
I will repeat my tests with improved diagnostics and will inform you about the
results.

Do you know JDO (Java Data Objects), the new SUN spec for Java-persistence.
Last weekend I heared of it for the first time. In some respects it seems to
be a succecessor to ODMG.
I also discovered CASTOR, and open source project by EXOLAB. They have
implemented JDO. quite interesting approach. There are some similarities to
ObJectBridge, but their code is much more complex than ours and they are
already at release 0.8.9 !

They have a lot of interesting concepts (E.g. an OQL implementation... which
could be helpful for us)

best regards,

Thomas

[Objectbridge-developers] Re: Quid pro quo

[Thomas M. <tho...@ho...>]

Hi Mike,

maxomenos wrote:

> Hey there. I'm trying to implement ODMG for C, Perl and Python (I know the standard isn't
> defined; I'm pretty much going to be winging it.)

Do you want to implement an Object/Relational framework for those languages? Or do you want to
create new language bindings for existing ODMG compliant databases ?

> I have some Java and ODMG 3.0 experience;

Good! With which ODMG compliant databases did you work? I have some experience with Objectivity
and POET.

>
> I'll trade my work on some parts of your project, in exchange for your help with my project.
>
> My project is called Free ODMG (fodmg)
>
> Do we have a deal?
>

It's always good to share experiences and know-How! From your mail and the information provided
under http://sourceforge.net/projects/fodmg I did not catch what kind of software you want to
build actually:
- a new language binding for existing ODMG compliant DBs ?
- a odmg compliant O/R mapping framework to be used with RDBMS ?
- a Full fledged ODMG- compliant Object-Server with SQL backend ?

Please explain me your vision of this software.

Unfortunately I won't be a big help in most areas of your skill requirements:
no Perl, no Python, little C, no objective C.

But I'm a OO hacker for more then 10 years (Smalltalk, CLOS, C++, Java) and of course I've
started the ObJectBridge project.
here is a short introduction into my ojb-vision:

It's pure Java, no intention to port it to any other language.
It's a modular system containg of separately usebable components:
finished:
- A PersistenceBroker that allows to store, retrieve and delete arbitrary Java-Objects to any
JDBC-compliant RDMBS. This Broker uses an XML based Metadata repository that describes the O/R
mapping. The usage of such a repository allows to keep all information about persistence
separate from the business-objects that need to be persisted - no need of subclassing from a
special baseclass, no need to implement special interfaces. The broker does not implement any
transaction coordination. this has to be done by its clients. the broker does not implement
ODMG.
But: the Broker has some features that are very cool in the area of Java application servers: it
provides ObjectCaching, Connection pooling and support for Finder-methods. These features
improve the performance of certain J2EE-applications by a factor 2 - 5 !
- a very small framework (only a few classes) to build scaleable applications, providing a
Proxy-concept that allow lazy loading, dirty marking and smart updates.
- small demo apps that show how to build applications using broker and framework.
under development:
- an ODMG compliant ObjectServer, with mutltithreading, full transaction management. This server
is a client to the PersistentBroker. I.e. the Server does all the tx management, session
handling, lock handling, etc. But when it needs to materialize Objects or has to commit its
transactions it needs to access the underlying RDBMS and does this by calls to the
PersistenceBroker.
There is already a functional demo application that shows how application against this server
can be build. As of today the server is not quite complete but at least transaction handling is
there!
Feel free to experiment with our code. If you have any questions don't hesitate to ask!

I'm not quite sure about future direction of this project, but I'm thinking of extending it to
implement the upcoming JDO (Java Data Objects) API. This will be a great help in integrating OJB
into J2EE Application servers.
Of course this will be a somewhat different approach than a standalone ObjectServer!

regards,

Thomas

[Objectbridge-developers] Reader/Writer Locks and other such stuff

[Dixon-Peugh, D. <Dav...@tp...>]

Good evening.

I've been doing some work on ObJectBridge, and have made some
further progress.  First a note on CVS.

When I tried to connect to CVS from home, I was unable to get
to the "ojb" directory of ObJectBridge.  I dropped some work into
the "objectbridge" directory.  I've moved just about everything
that has been updated to "objectbridge" from "ojb" (as I can
get to both at work, but only one at home.)

Now, as for the changes:

ojb.server.ReaderWriterLock -

This class implements a ReaderWriterLock on an object.  Unfortunately,
we cannot enforce this lock (its up to the user to do that.)  There are
basically a couple of APIs:
	read( Trans )
	write( Trans )
	upgrade( Trans )
	release( Trans )

Right now, the locks are maintained in the TransactionImpl (wrong place,
should probably be in a LockManager or such.)

ojb.server.ObjectTransactionWrapper - 

This class maintains the state of a persistent object at the begining and
end of a transaction.  When the wrapper is aborted, the persistent fields
of the object are restored to what they were at the begining of the 
transaction.  

ojb.server.TransactionImpl -

This class has been modified to use the Reader/Writer locks as apropriate.
It has also been modified to build ObjectTransactionWrapper around all
objects
that a WRITE lock is acquired on.

It has been modified to have ObjectTransactionWrapper commit/abort where
apropriate.

ojb.server.TransactionAware -

This is an interface that the end-user can implement.  With the
TransactionAware iface,
you can kill a transaction which involves your object.  You can also clean
up in
the event of an abort.

Share and Enjoy!

David.