Kristofer,
The solution you suggested would work only if you can modify the database.
We are not so lucky and cannot in any way update the database schema.
thank you
Sachin
[EMAIL PROTECTED] wrote:
> Hi... not sure if this is any help but I read a very simple fix to the stale
> data issue a little while ago. Why not simply assign a Version attribute to
> each object, such as an int or something. When a data object checks out the
> information, prior to updating it simply insures that its version matches
> that in the database, if not then someone else modified it and incremented
> its version and you handle accordingly. This keeps it simple, and you're
> only comparing a single primitive value rather than each and every field in
> the dataset so as to reduce performance overhead. I'd be interested to know
> other methods for addressing the issue, especially the most efficient ones.
>
> bests,
>
> Kristofer Goss
>
> -----Original Message-----
> From: Sachin Hardas [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, October 31, 2000 10:57 AM
> Subject: Comparison of solutions for stale data checking and short
> transactions
>
> 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".
