Inconsistency in setxx and getxxx methods in CMP......


EJB programming & troubleshooting: Inconsistency in setxx and getxxx methods in CMP......

  1. Hi,

    I am facing a problem with setxx and getxx methods in CMP.
    Lets say there is a quantity of 5 available(order.getQuantity()=5). Now some user want 3 of these items.By the time user calls setQuantity(5-3) on this remote handle(order),the quantity may no longer be 5.The quantity might have been changed by somebody else before setQuantity method is called.

    Even if I do:
    This also wont work because of the above mentioned reason.

    Is there a way in CMP, I can handle this situation ?

    Thanks in advance for your help....

  2. What you are describing is called a "Diamond". The EJB spec requires that containers detect "Local Diamonds" and resolve them. So, if you are running a J2EE complaint app server without a cluster, the container *must* as per the spec resolve the local diamond and hence don't worry about it. However a "Distributed Diamond" is the same effect occuring across a cluster. The spec does not require containers to detect and resolve this one.

    Are you clustering? Which container?

    Dave Wolf
  3. I think using the database transaction isolation level REPEATABLE_READ would solve your problem, because that isolation level locks all rows touched during a transaction. So if another transaction tries to read the same row, it blocks until the first transaction has committed. Ergo, no inconsistency problems in a cluster. Sadly, Oracle doesn't support REPEATABLE_READ; you have to use SELECT FOR UPDATE in your SQL instead (that locks the selected rows).

    The preceding is called pessimistic locking. It would also be possible to use optimistic locking (transaction isolation level READ_COMMITTED) with e.g. overqualified updates, i.e.:

    UPDATE orders SET quantity = 2 WHERE id = 55 AND quantity = 5

    Then if the returned JDBC update count is 0, you know that somebody else updated the row between you reading and trying to update the row. You then have to take application-specific actions (e.g. re-read the row and try again).

    Because you're using CMP, your application server should take care of these details for you. Consult its documentation for transaction concurrency and locking information.

    Pietari Laurila