Unless your application can set the RDBMS isolation level, it can not optimize its use of optimistic locking. In JBDC, the RDBMS isolation level is set using the connection interface. Since OJB applications don't issue any JBDC calls (that is the whole point of using OJB) then OJB *MUST* be able to set the RDBMS isolation level. How is this done with OJB?
If you can't set the RDBMS isolation level through OJB then 1) you are stuck with the default which you probably will need to change on at least some transactions or 2) there is a way to do it outside of OJB and have OJB use it for the current OJB transaction. Jeff Boring Custom & Web Services Development AT&T Labs [EMAIL PROTECTED] -----Original Message----- From: Thomas Mahler [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 03, 2002 3:53 PM To: OJB Users List Subject: Re: ODMG and locking (follow up) Hi again, Boring, Jeff W, ALBAS wrote: > 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. As our ODMG implementation is based on the PersistenceBroker API. Of course you can define a PB based optimistic locking and use it inside an ODMG application. > 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. > Correct. The Pessimistic locking does only work accross multiple ODMG clients! > 2) If you want to use OJB and optimistic locking, you have to use OJB's > PB implementation. as explained above: OJB ODMG is a PB client application. Thus you can use optimistic locking also for ODMG apps! > 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) correct! > 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. not corect. the isolation level definitions in repository xml only affect the ODMG locking. > Questions, how do you change the isolation level of the > underlying RDBMS at run time As explained: We don't play around with DB isolation levels! the isolations levels in the repository are ODMG (and in the future OTM and JDO) isolation levels. > and does the isolation-level attribute of > the class descriptor have any effect when using OJB.PB? No. cheers, Thomas > > 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]> > > > > -- 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]>
