> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Cedric Beust
> Sent: Thursday, June 28, 2001 6:57 PM
> To: [EMAIL PROTECTED]
> Subject: Re: To scale or to be correct: that is the question
> Seriously, that's the whole point: we really don't know. We
> don't lock, we
> activate as many instances as asked and we send the UPDATES blindly to the
> database and let it sort it out.
EEK! We are talking about a CMP implementation, correct? You should, at the
very least, allow the developer to specify a "timestamp/uid" field to
prevent concurrent access. Better yet, perform the necessary verified
updates. I don't think verified updates works in all concurrency situations,
but it will handle most of them.
I would hope that any app server (not picking on WL here) that passes thru
CMP calls to the database comes with a big warning label! Effectively, I
think we would have to use BMP on our entity beans if we want scalability
*and* concurrency control.
> If your database is set to optimistic concurrency (the default
> for Oracle),
> that's what you will get, with the risk of rollbacks. If it is
> pessimistic,
> the UPDATES will be serialized. No rollbacks, but a risk for waiting as
> there can be contention on the row locks.
Not just contention...but deadlocks, no? If not, don't worry about it,
because we are talking about scaling. At this time, advocating pessimistic
locking in the container is suitable for only the most myopic
implementations.
jim
===========================================================================
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".
