Originally posted by Peter Vennel:
Is there a way to warn the client, if the record in the table has changed between the initial extract and update. I was under the impression that EJBs were handling this.
Originally posted by Peter Vennel:
But the only problem is that I will need to add that extra column in every table. Not sure how enthusiastic the DBA's will be to do this.
Originally posted by Peter Vennel:
But the situation for me here is that, I am migrating .net apps to J2EE. So the Database Schema is already in place. Adding extra column to all the tables will have repurcussion to all other systems touching it.
Check Data for Validity with Optimistic Concurrency
You can configure the EJB container to validate an Optimistic bean's transaction data before committing the transaction, to verify that no data read or updated by the transaction has bean changed by another transaction. If it detects changed data, the EJB container rolls back the transaction.
Note: The EJB container does not validate Blob or Clob fields in a bean with Optimistic concurrency.
Kyle Brown, Author of Persistence in the Enterprise and Enterprise Java Programming with IBM Websphere, 2nd Edition
See my homepage at http://www.kyle-brown.com/ for other WebSphere information.
Originally posted by Kyle Brown:
"When (for instance) you set up WebSphere to do that, it automatically does a very specific WHERE clause as part of its update where it compares every part of the EJB as it was originally read against the columns as they exist in the database."
Originally posted by David Harkness:
You can use optimistic concurrency without adding a column. Instead, all fields are compared against the row when the transaction is committed (probably by adding all the old values to the where clause).
Configure validity checking for a bean with Optimistic concurrency using the verify-columns and verify-rows elements in the table-name stanza for the bean in weblogic-cmp-jar.xml file.
Specify the concurrency mechanism for a bean by setting the concurrency-strategy element in the entity-cache stanza in weblogic-ejb-jar.xml. Because concurrency-strategy is defined at the bean level, different beans in the same application can use different concurrency strategies, as appropriate.
Originally posted by Peter Vennel:
Found the problem.
<cache-between-transactions>true</cache-between-transactions>
Optimistic transactions read using a local transaction to avoid holding locks until the end of the transaction. However, optimistic transactions write using the current JTA transaction so that the updates can be rolled back, if necessary.
If this *is* what you're doing, I don't see how caching between transactions should make the difference since this is all happening inside a single transaction.
Are you instead starting the transaction right before you modify the bean, or as a consequence of modifying the bean (CMT)?
One suggestion though: XDoclet. Instead of deployment descriptors, this is how I make my beans use the various WebLogic features.
Water proof donuts! Eat them while reading this tiny ad:
We need your help - Coderanch server fundraiser
https://coderanch.com/wiki/782867/Coderanch-server-fundraiser
|