• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

JPA - schema for situation where client can lock (pessimistic lock) records in database on server

 
Witold Marshal
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How to desing a schema in which remote client can lock (with Pessimistic Lock) some rocords in datebase on JEE server using EJB methods?
I would like to achive a situation in which remote client calls one EJB method which finds some etity objects, locks them (calls "find()" with pessimistic lock parameter to datebase) and return to the client. After receiving those objects client can modify them knowing that the records are still locked in datebase and nobody else can modify them in this moment. Then client may call another EJB's method which takes as parameters those imrpoved entity objects and merges them to Persistence Context and than commits session which fushes changes to the records and releases the lock that was put on them.
The problem is how to lengthen a JTA transaction beyond single EJB's method scope. In CMT Bean te transaction ends at the same moment when method edns so record lock will be released at the end of each method.
I suspect that in this case BMT statful bean should be used. But is it allowed to call in one EJB's method for UserTransaction "tx.begin()"and then in second method "tx.commti()"?
Or maybe there is another way to achive the mentioned goal?

PS.
I don't want to use Optimistic Locking.

Do you have any link to site where some designe patterns (like this above) are described?
 
James Sutherland
Ranch Hand
Posts: 553
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't think EJB/JTA allow you to return to the client while leaving an open transaction on the database, but it may depend on the JEE server.
In general this is a bad idea, you will be locking the database for possibly a long time, and perhaps indefinitely if the client dies.
You may be able to do something if you don't use JTA, or perhaps even avoid the server's connection pools entirely.

You should really consider optimistic locking instead. You could also implement your own pessimistic locking where you add a locked column to your table, then you other clients would know that a client is editing this object.
 
Witold Marshal
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks.
I thought that it is possible but I couldn't figure out how.
So in some way Pessimistic Lock (which is connected with datebase locking) is useless because it can't prevent records from being modified during whole client - server conversation.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic