On Mon, 2 Jul 2001 15:15:59 -0700, Jonathan K. Weedon <[EMAIL PROTECTED]> wrote:
>It seems that the conversation about scalability is proceeding along rather
>well. Originally, I opened with some very strong statements about how
>certain appservers would have trouble scaling on certain databases.
>
>The conversation has proceeded on its own, and a number of the facts that
>lead to my original statement have been corroborated, independently. Let's
>review those facts.
>
>1) Some products do not support a "tuned" and "verified" update mechanism
>in their CMP engines, which is needed to support optimistic concurrency in
>the appserver.
>
Since we are talking about scalability here, I'd like to ask what kind of advantages
this OC at the appserver level has (versus at the DB level), if we have a cluster of
appservers. Or do you provide us with a distributed cache using OC?
>2) In the absence of appserver-based OC, the appserver must depend on
>the database to provide OC. By default, Oracle does not do so (that is, it
>lets through "stomping" updates).
>
I think the real question is whether the database supports OC or not, not what the
default setting is. Here it's clear that Oracle can support it - how about the other
DBMS? DB2, Sybase or SQLServer any idea?
>3) If you want to avoid "stomping" updates in Oracle, this means using the
>serializable isolation level, instead of the default isolation level. This comes
>with some performance overhead, which has yet to be quantified.
>
So you do agree that relying on the - properly configured - database to do the OC
doesn't corrupt the database?
With the example that's been used so far, Repeatable Read should be safe enough. AFAIK
Oracle doesn't support this level, so we have to use serializable here. How about
other databases support for Repeatable Read?
I'd like to know how you support applications that do need serializable transactions,
applications where phantoms have to be avoided. My experience has been that we take
the performance hit and use transaction serializable by default, since the EJB spec
recommends not changing the isolation level in the middle of a transaction.
>Now, let's continue with a thought experiment.
> ...
>[Note: some appservers have a proprietary extension to communicate to
>the persistence manager whether an entity was modified. This thought
>experiment is based on the use of EJB compliant entity beans, which by
>definition do not include such proprietary hooks. Admittedly, this line
>of argumentation does not hold if you are willing to litter your "container-
>managed persistence" entity beans with bean-managed persistence-
>tracking logic.]
>
This is the kind of proprietary optimizations we have to use indeed. I'd prefer the
application server to do this for me as well, but if the AS doesn't, you really have
to do it yourself. If you accept this or if you are using EJB 2.0 already, there are
no further implications on the performance.
-----
Peter Verkest
===========================================================================
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".
