Discussions

EJB design: Concurrent Access in EJB

  1. Concurrent Access in EJB (3 messages)

    I'm fairly new to EJB programming and I came across a roadblock in understanding concurrent access.

    I understand that a web page is stateless and that EJB can be stateless or stateful (sessionBean).

    What happen if I have two users accessing the same product page over the web and want to modify it. Here is what I think will happen:
    1- The two users should see the same product information
    2- User1 makes a modification and submit his changes. His changes are processed inside a transaction and commit successfully. User 2 hasn't started a transaction yet.
    3- User2 makes a modifcation (he should see product information prior to user1's changes) and submit his changes. His changes are processed inside a transaction and commit successfully but it wipes the changes from user1.

    In the example, entityBean are beanManaged.

    To overcome this problem, I started thinking about a version mechanism.

    If you have any idea on this please reply

    Threaded Messages (3)

  2. Concurrent Access in EJB[ Go to top ]

    Hi
    The query athat you have asked can occur ian all sort of application including the client server application.

    Let us take a simple case which we are all familiar with.

    The Flight reservation System. Assume that for a flight only two tickets are available andd ten people are trying to get a ticket for that flight from 10 different places.

    Assume that the sytem is not well designed. What happened will all the 10 people will get a postive reply that seat is available. (Assuming that they are requesting at the same time). Two lucky people will get the ticket and for the others at the time of processing the System will throw the Error or inform that Tickets are not available.

    So a work wround to this solution is lock the record, when the operator asks for the seats available. So that whatall count displayed in the screen will be valid. So the information passsed to the customer will be valid. But for this the operator must skip that option immediately after use, else the table get locked , preventing others to use it.

    So the best solution is Lock the table preventing others to view and unlock it immediately after use. But make sure that the sytem will unlock it automatically safter a certain idle time.

    the question you have asked has got some similarity to the above mentioned application.

    In your query you have mentioned that the Web pages are Stateles. But there is a concept called Session or Session Tracking.

    For example assume that there is an Online Bank and person logs in , did the transcation and left after logging out. Another person can go to the previous page using the Back button in the Browser and do some illegal transcations. For tracking all these a concept of session tracking is introduced.

    In the case of a Session bean, a single Instance of the bean will be used for serving all the client request. that is for the entire session you will be dealing with a single instance of the client.

    In the case of stateless session bean, the client will be getting different instance of the bean each time.

    thus it is for session tracking, EJB has priovided Stateless as well as Staefl sesion beans.
    Another way through which session tracking is possible is using Cookies.

    suresh

  3. Concurrent Access in EJB[ Go to top ]

    That means if we don't want to places lock on the underlying DB (perhaps other user may perform query/search on the records), then we need to perform some version checking/timestamp to make sure the record have not been modified since last read ?
  4. Concurrent Access in EJB[ Go to top ]

    Other discussion I had around that seems to point in that direction since locking the database is not acceptable to me. If you think back of applications developed in client-server with tools like Delphi and PowerBuilder, the record a user was modifying was cached then compared with the one in the database before commiting the transaction. That's why you would sometime get the "record modified by another user". Using a timestamp or a version is usually less resource consuming.

    JS