You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-user@db.apache.org by Fiona Magner <f_...@hotmail.com> on 2004/07/26 18:27:57 UTC

Problems with locking

Hi there,

I am having some problems getting a lock on my objects when I place my application under a small bit of pressure. I have two tables, a Clients table and a Messages table. The Messages table has a clientid field in it but I have not explicitly set any relationships with the Clients table in my repository descriptor as there may not always be a clientid value in the field (as well as the fact that I do not need any relationship expressed). Anyway I have a sample script that is reading from my clients table and then doing an insert into my messages table. This works fine except for when I request this script many times in which case the insert into the Messages table fails due to the following error:

org.odmg.LockNotGrantedException: Can not lock [AdminID] null ClientID] 12345 [Comments] test [DateCreated] {ts '2004-07-26 17:19:11'} [ID] -2 [LastUpdated] {ts '2004-07-26 17:19:11'} [Message] test for WRITE at org.apache.ojb.odmg.TransactionImpl.lock(TransactionImpl.java:236) 

When I remove the read from the clients table before the insert into the Messages table I cannot seem to reproduce it. So if I am only doing inserts into the Messages table it seems to be OK? I have gone through the lock management documentation to see if I am missing anything. I have set all my class descriptors to have isolation="read-uncomitted". I have also changed the OJBProperties file to have ImplicitLocking=false to see if that could help. The lock manager in OJBProperties is set to the default of LockManagerClass=org.apache.ojb.odmg.locking.LockManagerDefaultImpl. If anyone has any advice on something else I could try I would really appreciate it. This application really needs to be able to stand up to high performance and its falling over when I simply do multiple requests of this script within a few seconds of each other.

Thanks as always for your help!

Fiona