wood burning stoves 2.0*
The moose likes EJB and other Java EE Technologies and the fly likes EJB and Concurrency Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "EJB and Concurrency" Watch "EJB and Concurrency" New topic
Author

EJB and Concurrency

Luciano A. Pozzo
Ranch Hand

Joined: Jun 20, 2005
Posts: 112
Hello!

I have another newbie question, but I cannot find the answer!
I have two guys, that execute one EJB method (session CMP). If they access on same time, how the container manage this problem? One guy should wait another that executed first finish the method?

Thanks
Scott Selikoff
Saloon Keeper

Joined: Oct 23, 2005
Posts: 3703
    
    5

That's a pretty general question with a lot of potential answers depending on your performance and integrity requirements. In general though, I support optimistic locking mechanisms, that being they both try to execute and whoever finishes first wins, whereas the second guy gets an error and has to retry.


My Blog: Down Home Country Coding with Scott Selikoff
Luciano A. Pozzo
Ranch Hand

Joined: Jun 20, 2005
Posts: 112
Hummm.... error?

My idea, is that who start the method before, should execute complete... and another waits. Or, maybe the container do some type of chaining that execute the method on same time but taking care with race conditions.
I want to know if the container manage the concurrency, and if it's true, how?


Thank-you for reply.
Roger Chung-Wee
Ranch Hand

Joined: Sep 29, 2002
Posts: 1683
Ir depends on the server. For instance, the default strategy of WebLogic Server is database concurrency. Instead of trying to manage locks by itself, WebLogic Server creates a new bean instance for each transaction that wants to access that bean, and delegates concurrency control and deadlock detection to the underlying database. This is like running parallel database operations from multiple clients against a single database; the database's isolation level and locking policy will dictate which updates, selects, and inserts proceed and in which order, and what (if anything) is going to fail.

Other servers may do this differently, so you need to look at their documentation.


SCJP 1.4, SCWCD 1.3, SCBCD 1.3
Luciano A. Pozzo
Ranch Hand

Joined: Jun 20, 2005
Posts: 112
Hummm..... ok, but the EJB specification indicate that they should resolve this (concurrency), no? Because the question is: if I have concurrency, the server manage that? or just send an exception with a message: "sorry somebody requested before you this method!"
Scott Selikoff
Saloon Keeper

Joined: Oct 23, 2005
Posts: 3703
    
    5

It depends on what you are using for persistence management. For example, JDO will throw optimistic locking errors named appropriately that you have to catch and do something with. Others, like JDBC you often have to check for optimistic locking errors (often using a timestamp) yourself.

It sounds like you'd prefer a pessamistic locking error such as programs that lock an entire table or database while others wait... To be frank, pessamistic locking of any kind is not good in practice. The performance impact is detrimental.

The best you can do is row-level pessamistic locking but that only prevents duplicate modification of entries doesn't prevent duplicate entries from being inserted at the same time. For example, two queries might both look for the sum of the prices in the database, perform some mathematics on them, and then insert records based on that math. Since the two new records did not know about each other, and therefore could not lock each other, they could be later inserted with false data. Like checking to see if a user exists while creating a user ID... two separate users creating the same id would not neccessarily block each other.
Roger Chung-Wee
Ranch Hand

Joined: Sep 29, 2002
Posts: 1683
Luciano, you should read the EJB spec. The spec requires that the container will ensure appropriate synchronization for entity objects that are accessed concurrently from multiple transactions but does not specify how it should be done.

I've explained one way of doing it. Another way is for the container to acquire an exclusive lock on the record in the DB, to have a single instance of the bean synchronized with the DB and serialize the access from multiple transactions to this instance. This is not good for overall performance, so most EJB server vendors will not do this.
Luciano A. Pozzo
Ranch Hand

Joined: Jun 20, 2005
Posts: 112
Hummm.... great!

I understood, so, what can I do with this?



This is a session stateless method, that read (meioPagamentoDAO.meioPagamentoLoad(meioPagamentoInterTO.getId())) and update(meioPagamentoUpdateFlagRecebimento(meioPagamentoInterTO, new Integer(1))) on database. These two operations should be atomic, but I'm using simple JDBC. So I thought that the session avoid such things, what can I do to solve it?
Roger Chung-Wee
Ranch Hand

Joined: Sep 29, 2002
Posts: 1683
You are using a session bean and JDBC to update the DB. That's fine. If you were to use a CMP bean, you would not need to write any SQL.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: EJB and Concurrency
 
Similar Threads
How to servlet invoked secured EJB in JBOSS
How to EAR
Get EJB Home from another EJB method?
EJB introspection
EJB Transaction