• Post Reply Bookmark Topic Watch Topic
  • New Topic

Pessimistic locking across transcations  RSS feed

 
manish kkum
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I have to implement pessimistic locking across user transcations. I am using CMP EJB for reading and editing the database field. My requirement is that once one user is editing one CMP EJB , other user can't edit the same CMP; they can only view it.
I know, Websphere (my app server) provides different locking mechanism but they are within a transcational context. My requirement is across transcations. I wanted to implement Version number pattern of EJB , but it is for Optimistic locking. The client requires the Pessimistic locking i.e once one user get a CMP for editing, other user can't edit on that CMP.
Any help will be highly appreciated.
regards,
manish
 
Kyle Brown
author
Ranch Hand
Posts: 3892
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't think you understand how WebSphere's access intents work. They DO work across transactions -- that's the whole point. As a start, you may want to read this excerpt from the chapter in my book on EJB transactiosn in WebSphere. However, you probably also want to read on the topic in the InfoCenter as well.
Kyle
 
manish kkum
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Kyle,
thanks for the reply.I would really grateful to you if you could tell me variable name suitable to my requirements. I tried to go through the excerpt but couldn't get the idea how it is going to manage concurrenvy issue across transcations. It talks about within transcation context only.
thanks in advance.
regards,
manish
 
Kyle Brown
author
Ranch Hand
Posts: 3892
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm sorry Manish, but I don't know how to explain the concept any clearer. Any of the pessimistic options would work for you, but it depends on what level of concurrency you are willing to put up with (e.g. will you allow phantom reads, etc.).
If you really don't understand this, I'd suggest you go with the exclusive option. It's probably better to err on the side of caution.
However, from your post it seems like your customer wants the EJB to be locked through the editing process -- e.g. from the time they read the EJB and create the form for editing through the time the form is submitted and the EJB is updated.
That is not possible. That's not the way that EJBs (or databases in general) work. You can't lock an Entity bean for a long time across multiple transactions like that.
Kyle
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!