I'm using OJB 1.0 rc3 with WebSphere 5.0 J2EE Stuts 1.1 client using the default object cache implementation.
This is occuring right after a transaction rollback due to a database error (org.apache.ojb.broker.KeyConstraintViolatedException:) in a call to pb.store(obj). The update method was 1 pb.beginTransaction() 2 pb.store(obj) --> raises KeyConstraintViolatedException 3 pb.commitTransaction() After the exception I can only refresh obj if: in the first method 1. removeFromCache(obj) 2. getObjectByQuery return from that method in the second method 3. removeFromCache(obj) 4. getObjectByQuery obj is now refreshed Steps 1 and 2, by themselves do not refresh the object reference with database values. If I omit step 2 and just do steps 1, 3 and 4, the object is also not refreshed. If step 1 is a pb clear cache, the cache is indeed cleared and the object is refreshed. Apparently the object Hashtable cache in the web container is not letting go of the reference unless it is removed from the cache in a second method but only after the first method attempts a retrieval first. Maybe the getObjectByQuery in step 2 forces OJB to "let go" of the object after since the exception was raised during the pb.store() and the commitTransaction() was never invoked due to the exception? Should I clear the transaction in the catch block somehow? In a regular java OBJ client, the remove from cache works fine and only has to be called once. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
