Problem : Comparison of solutions for stale data checking and short transactions.
Notes :
1. Client uses EJBs to perform certain transactions on the database.
2. Entity beans hold business object which contain all the data
associated with the entity bean.
3. Using BMP.
4. Shared Database. Can be modified by other applications
asynchronously.
5. The container guarantees that each individual client would have its
own entity bean to modify.
Typical scenario :
Client would get business object from entity bean to set certain values
on it. Client executes an operation on a Session Bean.
But, we need to tackle the problem of stale data because of a highly
shared database. So while committing the actual transaction, check if we
are manipulating the same data that client used before initiating the
actual database transaction.
Solution 1 : Using a stateful session bean.
Client interacts with a stateful bean to begin/commit/rollback
UserTransaction on it.
Client -> statefulBean.begin()
Client -> statefulBean.getBusinessObject()
Client -> manipulates the business object
Client -> statefulBean.setBusinessObject()
Client -> statefulBean.doOperation()
Client -> statefulBean.commit().
The client starts a transaction here but the current implementation
ensures that the database is not locked until the final commit.
There are two issues involved here
1. The duration of the transaction is long. The client starts the
transaction at the beginning of every operation and only commits it
after its finished with the operation. The default isolation level on
the database is READ_COMMITTED.
2. Even if state is maintained by the stateful session bean using
userTransaction, there is a concern about scalability of this model for
huge number of client (in tens of thousands).
Solution 2 : Remembering original state in the business objects. Use
stateless session bean.
The business objects have their original state stored in them and this
data is passed back by the client to the stateless session bean. The
bean then compares the original copy of the data in the client with that
in the database and executes the operation on a match.
Client -> gets the business object from the factory.
Client -> manipulates the business object
Client -> statelessBean.doOperation(BusinessObject.... )
The doOperation commits data upon completion. The transaction lasts only
for the statelessBean.doOperation().
There are again two issues involved here
1. statelessBean.doOperation compares values of the business objects
with current database values (field by field) to verify for stale data.
2. The original state of the business object passed to the client can
sometimes be large and can attribute to some significant network
traffic.
We have found the above two solutions. We would appreciate your comments
on each of them and your suggestion on which one would be best suited
considering flexibility and future scalability.
Please advise
Thanks
GPS Team
______________________________________________________
Get Your FREE FlashMail Address now at http://www.flashmail.com
It's Free, Easy, & Fun !!!
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
