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]>
