I'd like to use OJB with the ODMG interface, in a servlet container. Lots of other, non-Java applications talk to the same database. We manage concurrency problems with optimistic locks. Every app checks a timestamp when it updates a record, and aborts its transaction if the timestamps don't match. We have to use this approach. I assuming I can still use the 'locking' attribute on my timestamp field, with the ODMG API?
I don't need or want any extra locking functionality. I don't want two different threads in my servlet container contending for an OJB LockManager lock. The LockManager looks great, but in my situation it doesn't buy me anything, and I don't want the overhead. I do, however, want to use the ODMG api because I like OQL, and because I like the fact that ODMG keeps track of what objects need to be updated at commit time. What's the best way to turn locking off? I implemented a dummy lock manager, that does nothing, at that seems to be working OK. But is that the best way? I still call org.odmg.Transaction.lock on new persistent objects, but only because I want the side effect of having the object registered with the ODMG transaction, so it will get inserted at commit time. Is there a better approach? Here's what I want to happen with each servlet request: 1. Start an ODMG transaction. 2. Do stuff with persistent objects. 3. If no errors, commit the transaction. 4. Clear out the ObjectCache, any other state associate with this transaction I want each thread to be totally independent. Within the same thread I want to use the ObjectCache to prevent duplicate copies of the same object, and to avoid unnecessary db reads. But I don't care if another thread has a copy of the same object. In other words, I want I separate ObjectCache per thread. Is this possible? Thanks! Steve Molitor -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
