Thank you Thomas, A quick solution was to remove instances from cache for the particular class that I'm concerned with as they are retrieved (solution #3). That was quite easy to implement. I have many other classes that *should* have shared references, so it doesn't make sense for me to make all caching "empty" (solution #1). Probably for me, the most efficient solution would be to implement my own cache that properly deals with the lifecycle of the objects in my system (solution #2).
Thanks again for you help, Mark Thomas Mahler wrote: > > Hi Mark, > > Mark Howell wrote: > > 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. > > 1. you can tell OJB (in OJB.properties) to use the EmptyObjectCacheImpl. > This cache does not hold any references and thus avoids the problem you > mention. > > 2. You could implement your own cache, that internally maintains a > separate cache for each thread. > > 3. You can make your threads work with local copies rather than globally > shared instances. > After loading an instance with the PB call PB.removeFromCache(instance); > If other threads load the same object they will be served with a fresh > copy of instance. > Of course you should use optimistic locking to avoid write conflicts. > > > > > Would I need to use the ODMG API to do this currently? > > Of course ODMG does most of the work automatically. But as mentioned > above, you can also do this with the PB. > > > If so, can I use > > the PB API and ODMG concurrently on the same repository/db? > > > > yes! There is a sample for this in faq.html. > > cheers, > Thomas > > > 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]>
