----- Original Message -----
From: "Eddie Fung" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, September 29, 2000 2:23 AM
Subject: Re: Real-world limitations of simplistic optimistic concurrency schemes
> > Few databases support row-level locking (anecdotal, maybe this has
> >changed), and those that do are often deployed with page-level locking for
> >performance reasons.
> Actually I believe Sybase, Oracle and DB2 all support row level locking. I
> think IBM suggest using page level locking where possible because of the
> overheads in maintaining row level locks
OK, thanks. Our DBAs have discouraged the use of row-level locking on our Sybase
databases for exactly the same reason.
> > With page-level locking, many transactions would be
> >falsely rejected because they are "too close" too a record that is being
> >modified.
> Actually this should result in a deadlock at page level rather than false
> rejection
True, a deadlock exception is raised. To the developer, this appears as a
SQLException. They must retry the update. This get's into another pet-peeve area
of mine. We need a set of standard JDBC exceptions defined and supported by JDBC
drivers so we can tell the difference between UniqueIndexException,
DuplicateRecordException, DeadlockException, etc.
> I agree with you but I keep thinking that the problem is that most
> application servers are using the ejbLoad at all costs from the database
> ala WebLogic and Websphere and that the problem is that few app servers
> actually keep the object state in between transactions. IF they did and IF
> the only way that data can be updated is via the application
> server/container, then some of these concurrency issues MIGHT disappear. I
> believe that Gemstone/J and perhaps Persistence PowerTier may do this. I
> also believe that IBM San Francisco may also have done this.
The concept of caching state *is* supported by every major EJB vendor. The
problem is that this approach fails miserably in a clustered environment. I
should add that this approach (even in a single ejb container scenario) is not
very practical in *real-world* applications.
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".
