Hi all, Please pardon me, my ODMG ignorance is shining through ;)
Mark Thomas Mahler wrote: > > Hi again, > > Anil is right. But the Isolationlevel stuff does only work inside the > ODMG layer. It is not implemented on the PB level! > > The isolation-levels in the repository have nothing to do with isolation > levels on the database levels. They are not translated into JDBC calls. > They just specify the behaviour of the OJB/ODMG Lockmanager. > > cheers, > Thomas > > Mark Howell wrote: > > Anil, > > > > I think that attribute option has to do with database interaction, and > > not with how the PB and it's cache materialize and distribute objects. > > I'm not sure about this, but I've tested several of these modes > > including serializable, repeatable-read and read-uncommitted and none of > > those modes made the PB return distinct instances of an entity to > > multiple threads. My tests were only with the PB API. > > > > Thanks, > > > > Mark > > > > > > Anil Sharma wrote: > > > >>Wouldn't specifying the transaction isolation level to > >>"RepeatableReads/Serializable" for the class(es) in question achieve that ? > >> > >>Here's an excrept from lockmanager documentation :: > >> > >>///// > >>The ODMG specification does not prescribe transaction isolationlevels or > >>locking strategies to be used. Thus there are no API calls for setting > >>isolationlevels. OJB provides four different isolationlevels that can be > >>configured for each persistent class in the XML repository. > >>The isolationlevel of a class can be configured with the following attribute > >>to a ClassDescriptor: > >> > >><ClassDescriptor id="1" isolation="read-uncomitted"> > >>/////// > >> > >>I am using PB Query objects (PB API) within ODMG transactions (ODMG API) - > >>so I believe you can use both of them on the same repository/db. > >> > >>HTH > >> > >>Anil > >> > >>-----Original Message----- > >>From: Mark Howell [mailto:[EMAIL PROTECTED]] > >>Sent: Monday, October 14, 2002 5:38 PM > >>To: OJB Users List > >>Subject: Re: objects > >> > >>Hello, > >> > >>Is there a way to force the PB to *not* share local instances of an > >>Object that it finds with multiple threads? I would prefer, for at > >>least some of my classes, that one thread not see the changes made by > >>another unless that object was specifically stored in the PB. > >> > >>Would I need to use the ODMG API to do this currently? If so, can I use > >>the PB API and ODMG concurrently on the same repository/db? > >> > >>Thanks, > >>Mark > >> > >>Thomas Mahler wrote: > >> > >>>Kevin Viet wrote: > >>> > >>>>If two threads query the API for this object, they share the same > >>>>reference on this object. > >>> > >>>correct. > >>> > >>> > >>>>So if a thread change a value (without update the object through the > >>>>API) of the object, the other thread will see this change (even for the > >>>>object cache) > >>> > >>>correct for PB API. For ODMG we have a pessimistic locking that will > >>>protect against such conflicts. > >>> > >>> > >>>>Won't any problem arise if thread1 change some values and thread2 is > >>>>commiting the update. > >>> > >>>correct > >>> > >> > >>-- > >>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]>
