OK, so if I understand this correctly: 1) OJB's implementation of ODMG does not support optimistic locking, instead implements its own object based locking using a pessimistic strategy and ignores the underlying RDBMS. I don't understand how this would ever work, unless perhaps all accesses to the RDBMS were based on OJB.ODMG, but that's another matter.
2) If you want to use OJB and optimistic locking, you have to use OJB's PB implementation. In OJB.PB, optimistic locking is implemented by an application thru a] specifying true on the locking attribute of the field descriptor (for TIMESTAMP and INTEGER columns) and b] setting the isolation-level attribute of the repository descriptor to an isolation level of the underlying RDBMS that is consistent with optimistic locking. Questions, how do you change the isolation level of the underlying RDBMS at run time and does the isolation-level attribute of the class descriptor have any effect when using OJB.PB? Jeff Boring Custom & Web Services Development AT&T Labs [EMAIL PROTECTED] -----Original Message----- From: Thomas Mahler [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 03, 2002 6:40 AM To: OJB Users List Subject: Re: ODMG and locking (follow up) Hi again, Boring, Jeff W, ALBAS wrote: >> The OJB isolation levels *do not* touch the db! They only concern >> the ODMG object level tx management. The isolation levels of the >> underlying RDBMS are not used by OJB! < > > > OK, now I am really confused. What do you mean by "OJB isolation > levels?" Are you not referring to > java.sql.connection.setTransactionIsolation(int level)? exactly! > Unless OJB is > using some magic that I am unaware of, "RDBMS isolation levels" ARE > always used, at least the default isolation level for the specific > RDBMS. Sure the RDBMS always uses it's internally set up isolation strategy. But OJB provides it's own lock management mechanism! If objects are read from the db, OJB does not lock the associated rows for update in the db! The OJB ODMG provides a Lockmanager that provides its own mechanims to implement pessimistic locking on an *object* level. > Does this have anything to do with the LOCK TABLE sql command > I heard OJB used? OJB is not using any RDBMS feature to provide locking. There is no "LOCK TABLE" command issued by OJB! > > Obviously there is a information gap on my part here. If you can, > please point me to where I can go to read more about this. Thanks, > Please see: http://jakarta.apache.org/ojb/lockmanager.html I hope this document will answer your questions. (If you are not using the ODMG API you can use the PersistenceBroker optimistic locking feature based on timestamps or version fields.) cheers, Thomas > Jeff Boring Custom & Web Services Development AT&T Labs > [EMAIL PROTECTED] > > -----Original Message----- From: Mahler Thomas > [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 02, 2002 > 8:16 AM To: 'OJB Users List' Subject: RE: ODMG and locking (follow > up) > > > Hi, > > >> I read this tread about locking and want to make sure I understand >> object cache locking verses RDBMS locking. Locking as discussed in >> that tread (implicit) as well the as org.apache.ojb.odmg.locking >> interface has to do with the object cache, not share/exclusive >> locks applied to the rows of the database (for RDBMS with row level >> locking)? Right? > > > Correct! > > >> RDBMS locking is controlled solely by the isolation level and the >> specific DML issued, right? >> > > > The OJB isolation levels *do not* touch the db! They only concern the > ODMG object level tx management. > > The isolation levels of the underlying RDBMS are not used by OJB! > > cheers, Thomas > > >> Jeff W Boring [EMAIL PROTECTED] 813.878-3367 (work) >> >> >> -- To unsubscribe, e-mail: >> <mailto:[EMAIL PROTECTED]> For additional >> commands, e-mail: <mailto:[EMAIL PROTECTED]> >> > > -- To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> For additional > commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > -- To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> For additional > commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
