• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Help , A simple question regarding CMP Entity Bean

 
Ranch Hand
Posts: 142
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi All,
I got a simple question regarding CMP Entity Bean.
Suppose I have a Entity Bean to represent the number of a critical resource. Each time when some need the resource , it would query this Entity Bean first , if the number is greater than 0 , it would update the counter member of the Entity Bean and get a resource.
My question is if there are concurrent requests , how does the container or do I to handle it?
Suppose there are 2 requests , then there would be 2 instances of that Entity Bean in the memory . Is it possible that there is only one resource available and both requests can update the Entity Bean successfully because there are 2 Entity Bean instances in the memory?
How to handle this? Will the container handle it automatically?
Thanks for your help.
Lin
 
author
Posts: 3892
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
My advice would be to rely on database locking and transaction isolation to make this work. If your finder method issues a SELECT FOR UPDATE (which is configurable for most app servers) then you can be assured that no other bean instance can get to that same data. So I'd make sure I would do the following
(1) Start the transaction through a Session bean (declaratively)
(2) Do a findByPrimaryKey() to locate the entity (configured to do a SELECT FOR UPDATE)
(3) read/update the entity bean
(4) let the transaction commit.
Kyle
 
Lin Feng
Ranch Hand
Posts: 142
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If so , the Entity Bean should never be exposed to other directly. There should be a Session Bean to act as delegation to access the it to prevent someone just called the findByPrimaryKey and locked the table for a long time.
right?
 
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Suppose there are 2 requests , then there would be 2 instances of that Entity Bean in the memory .


Is this statement correct?
 
Ranch Hand
Posts: 1066
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am not an expert in EJBs but will give this a try...
Approach 1:
How would I do it if I use plain JDBC to do the above task?
1. Open transaction
2. Select data
3. If conditions meet, Update data
4. Close transaction
And would wrap this code in a synchronized method or block, but EJBs forbid the use of synchronization in the bean code!...So would follow Kyle's idea of the SELECT FOR UPDATE clause...
I would put the SQL code in a simple method of a Stateless Session
bean to accomplish the above task with BMP and CMT.
Approach 2 :
Since the number field and the counter member fields belong to the same entity bean, I would write a home business mehtod in the home interface which performs the Select and update actions together. I guess we still need to use Select For Update clause as locking is required...I know, it can be done using BMP but not sure how you do it in CMP, if your bean is already CMP2.0 :roll:
Whenever we use Select For Update clause, we make sure that we release the lock on the rows as soon as possible, after we are finished with updating. Otherwise this could turn to be a performance issue in the code later...
 
Kyle Brown
author
Posts: 3892
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by LIN FENG:
If so , the Entity Bean should never be exposed to other directly. There should be a Session Bean to act as delegation to access the it to prevent someone just called the findByPrimaryKey and locked the table for a long time.
right?


No -- remember that declarative EJB transactions only last as long as the outermost method scope. Long running transactions (lasting seconds or minutes) should never occur in that environment. And usually when you call a findByPrimaryKey it's because you want to update it -- otherwise it's usually located by some other finder method (such as one that finds by some parameter or other).
Kyle
 
Kyle Brown
author
Posts: 3892
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Joseph Jegan:

Is this statement correct?


I believe that this depends on a number of factors, such as the Commit option being used, and how the vendor chooses to implement their beans, but the answer could certainly be yes. However, consider the more common case where the same EJB (e.g. representing the same table row) resides on more than one application server that has been clustered. In this case, the ONLY option to handle this is through database locking, which is why the application server vendors provide this capability.
Kyle
[ December 13, 2003: Message edited by: Kyle Brown ]
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic