We are running into major issues when more than one user attempts to do updates in the database to the same rows. Is there a way to make WebLogic queue these requests from the clients? From the WebLogic documentation: Special note for Oracle Databases Keep in mind that Oracle uses optimistic concurrency. As a consequence, even with a setting of TRANSACTION_SERIALIZABLE, Oracle does not detect serialization problems until commit time. The message returned is:
java.sql.SQLException: ORA-08177: can't serialize access for this transaction Even if you use the TRANSACTION_SERIALIZABLE setting for an EJB, you may receive exceptions or rollbacks in the EJB client if contention occurs between clients for the same rows. To avoid these problems, you must ensure that clients catch and examine the SQL exceptions, and take appropriate action, such as restarting the transaction. >> end WebLogic documentation If this is all true, why exactly would we purchase such an expensive hunk of **** if we have to manage the transactions ourselves? Anyone else running into this?
Nothing I've ever read in the EJB spec ever indicated to me that EJBs were expected to resolve high-level contention issues. There are too many ways of doing so to force just one on the system designer. I think what they are getting at has to do with concurrent access from users outside the EJB system -- that is, when users update from both WebLogic and, say, a console client SQL request. Read that way, I'd take it as simply meaning that when a row is fetched as an EJB, there's no lock that can be acquired within Oracle to tell WebLogic not to reject the EJB changes out of hand -- instead you get a failure when the bean is saved to persistent storage. It's possible that among the concurrent clients where this might occur would be multiple WLS servers in a cluster. You might seek clarification on the WebLogic-specific newsgroups (BEA's own, in particular) and/or those pertaining to Oracle.
Science is the process of replacing what we "know" with what is TRUE. Politics, alas, often prefers to be the opposite.
I'm too green a horn to be able to comment why its not available.. But I did have a similar problem in an application I worked on.. We had to resolve it ourselves.. We did it by having a Timestamp column in the table.. Every read from the table reads the timestamp too for that row.. Every update on that row updates the timestamp to current server time.. Now if a second user updates the row after a first user has read it and then when the first user tries to update the row, the timestamp that he read and that which is on the row now do not match and we do not update.. a simple where conTimeStamp = etc.. etc.. as part of the update statement..
If you settle for what they are giving you, you deserve what you get. Fight for this tiny ad!