This one time, at band camp, michael simons said:
ms>one of the benefis of an object persistent framework like Castor JDO is
ms>that it encapsulates the different RDBMS.
ms>
ms>But in the following case Castor JDO does not and I don't know how to work
ms>around...
ms>
ms>Assume a simple class
ms>class Customer {
ms> int id;
ms> java.lang.String name;
ms>}
ms>
ms>This class is mapped to a simple table CUST ( id integer primary key, name
ms>varchar(32) ).
ms>
ms>Two instances of my program are running,
ms>
ms>In the first one the user creates a new customer, so Castor executes an
ms>insert into the CUST table.
ms>The transaction is still pending.
ms>
ms>In the second one the user trie sto get a list of all existing customers.
ms>This query is executing successfully with Oracle but it fails when using MS
ms>SQL Server or SAP DB (MaxDB) after the request timeout, because these
ms>databases achieve the isolation level "committed-read" by locking an
ms>inserted record exclusively and locking a selected record shared.
ms>
ms>This difference could be encapsulated by Castor JDO by treating insert the
ms>same as update/delete where the SQL statements are deferred until the
ms>transaction is committed.
ms>
ms>Please let me know what You think about this problem? Did anyone solve the
ms>problem or work around it? Or is there a way to tell Castor JDO to defer
ms>the insert.
ms>BTW: The simple work-around to commit the first transaction (the inserting
ms>one) when the customer was created does not work in my application (a fat
ms>client) because there are more modifications that all together must be atomic.
Michael,
This can be addressed using the Castor locking mechanism (see
http://www.castor.org/locking.html). Castor's locking provides im-memory
locks to help avoid these types of situations.
I've also been wondering about exposing the database transaction
isolation level. The problem with the exposure of the database transaction
isolation level is that the same isolation level does not apply to all
situations. But it's similar to Castor's locking mechanism in the sense
that classes must be carefully mapped in order to satisfy all of your
requirements.
Along that same line, I have also wondered about implementing JDBC 3.0
savepoints. The problem with these is that not everyone is using JDBC
3.0. Maybe this could be implemented as an optional feature configurable
via the castor.properties.
Bruce
--
perl -e 'print unpack("u30","<0G)[EMAIL PROTECTED]&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
The Castor Project
http://www.castor.org/
Apache Geronimo
http://incubator.apache.org/projects/geronimo.html
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
