On Wed, Nov 20, 2002 at 03:53:29PM -0600, Molitor, Stephen wrote: > Jeff Boring wrote: > > > Note also that locking a described above is totally independent > > of the RDBMS locking. This is something I am currently struggling > > with because my app's RDBMS is used by lots of other applications > > and the ODMG object locking only works if every app using the RDBMS > > is using ODMG. > <snip> > > I just don't have a good feel for the issues with using ODMG in a > > mixed environment where all the other apps are using standard optimistic > > locking. > > Jeff, > > I'm struggling with the same exact issues. Since all the other apps are > using standard optimistic, I have no use for ODMG's locking. I mean, it > sounds great and all, but we can't change our locking strategy. So, can I > use ODMG without the locking mechanism? I have tried replacing the lock > manager with a no-op implementation, no problems so far. > > Another issue is the object cache. Since we're using optimistic locking to > catch concurrency errors, I want each thread in my servlet container to be > independent. I want to allow two concurrent threads to work on the same > object, and just let the optimistic lock check catch concurrency problems. > That's how all our other apps that hit this db currently work. Plus, I > don't want changes to an object by a request in one thread to be seen by a > request in another thread. Can I make the object cache 'thread local' with > ODMG? With PersistenceBroker?
I did this, look for "per thread caching" in the archives. I wrote my own cache implementation as a 'meta-cache' managing a cache for each thread. Since it works with PB, it should do with ODMG API, too. hth, Jens -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
