That certainly makes your task much harder.
At first you may think that you can separate the concurrency column (Kristofer's
version attribute) into another table. This may work if you can impose row-level
locking. There are other issues however that make this approach unusable.
Since you state that you cannot update the database schema in "any way", I
assume that you cannot add tables. I would argue that your legacy solution (the
one that uses the current schema) does not enforce concurrency, so why should
you worry about it? :-^)
Seriously though, sometimes concurrency is an unnecessary burden depending on
the application. Ask yourself, what are the chances that two ppl simultaneously
update the same object, and so what if they do?
jim
----- Original Message -----
From: "Sachin Hardas" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, November 01, 2000 9:38 PM
Subject: Re: Comparison of solutions for stale data checking and short
transactions
> 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".
>
>
===========================================================================
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".
