Evan,
<vendor>
This is a good question: is there any AppServer that has "done it
right". I know of at least one (not us), but unfortunately they
do it by providing a proprietary CMP model. Certainly none of the
"brand name" products provide this all correctly.
We currently support the ability to do CMP updates "in such a way
that update transactions never commit if they were based on stale
data". This is obviously a very important first step, since
otherwise your optimistic concurrency might stomp on previously
updated data. (And remember that as soon as you use clustering,
every appserver is providing optimistic concurrency, even if their
single container model uses pessimistic concurrency.) I wonder
how many EJB developers realize that this "data stomping" bug
exists in their code, at least when their code is run on Sybase
or Oracle. And I wonder how many EJB developers realize that
almost every example of BMP ever written in a book, product
example, etc., has this same problem. [Yes: our BMP examples
have this bug too.] Actually, I even wonder how many AppServer
vendors realize this bug exists in their products ;-)
We also provide an OptionA cache optimization, although today
this is not timeout based. (We are adding OptionA timeout
capabilities for the next release.) I know of other vendors
who have this OptionA cache timeout capability already.
Your thind requirement is a bit trickier. Of course, you need
to be sure that you do updates correctly. (And again, the
majority of products don't do this today.) But the problem is
that these consistency checks can fail, and thereby cause the
transaction to rollback. Simplistically, it seems desirable to
just retry the transation, in the expectation that when you
do it again, it is unlikely that you will hit another concurrency
collision. (And we are adding support for this simplistic
solution in our next release. Again, other vendors already
provide this capability, although without the update consistency
checking, it is a useless, or worse, a dangerous feature.)
Unfortunately, I don't think it is quite this simple. Yes, if
your transaction is read-only, it can be done over. (Actually,
if it is read-only, it is not an update transaction, and life
is simpler still.) But many transactions are not read-only.
This is still fine, if all the updates occur in the scope of
that same transation: you have to track what was modified, and
verify that it is all still valid (which we do). But what if
your EB calls another EB, which has a RequiresNew transaction?
Can this "sub" transaction be done over?
This issue would go away with the use of nested transactions.
Then we could execute "RequiresNew" sub-transactions as nested
transactions, and a transaction rollback would also rollback
the nested transaction. But the EJB spec does not support nested
transactions.
Thus, these automagic retry transactions need to either span
a single transaction, or multiple idempotent, repeatable, or
readonly transactions.
I'm not going to suggest a solution to this problem. Probably
explaining the issues to users, so that they understand what
the <transaction-retry> counter means, and how it can potentially
screw with their application, is all that can be done. I just
wanted to point out that (as always) it's not as simple as it
seems it could be.
</vendor>
-jkw
Evan Ireland wrote:
>
> "Jonathan K. Weedon" wrote:
> >
> > As you say: "CMP can have ... performance limitations unless you cut some
> > dangerous corners or you have a fairly complex CMP caching architecture."
> > That is, if you don't do things properly, you will either have terribly
> > slow CMP behavior, or incorrect CMP behavior. (Or, in the case of one
> > leading vendor, both.) So yes, you have to do it right, to make it fast.
> > But the correlary is that if you do take the time to do it right, it will
> > be fast.
>
> Are you are of any EJB servers that have "done it right" for standard EJB 1.1
> CMP, in such a way that update transactions never commit if they were based
> on stale data, transaction retry is automatic, and for read-only transactions
> you can specify a maximum time window for possibly stale data?
> ________________________________________________________________________________
>
> Evan Ireland Sybase EAServer Engineering [EMAIL PROTECTED]
> Wellington, New Zealand +64 4 934-5856
>
> ===========================================================================
> 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".
