On Mon, 31 Jul 2000 12:35:55 -0700, David Wall <[EMAIL PROTECTED]>
wrote:
>This thread has really gotten off the EJB track.
While I do understand your point, this is (unfortunately!) not correct.
Since the effects of different concurrency schemes gives radically
different behaviour it is necessary to dive into these rather
theoretical discussions. Pessimistic scheme=deadlocks possible,
optimistic schemes=rollbacks possible. Both are aimed at solving
concurrency problems, but since they are focused on making it easy for
the resource implementor (EJB container+DBMS) it is the component
developers that ultimately have to deal with it when the problems arise.
> Part of the "problem" is
>that people need to talk about some real products and implementations since
>most of us are concerned more with what can be done using EJBs today than
>what could be done in a theoretically environment.
Since its the pessimistic and optimistic concurrency schemes that are
the fundamental differences between how products implement concurrency
conflict resolution, I actually think it's more beneficial to discuss
these rather than specific products, since it is easier to apply the
results to a wide range of actual setups. If we chose the "practical"
approach we would have to enumerate all possible combinations and their
respective behaviour, which is somewhat impractical.
>For example, most people still use RDBMS, though OODBMS may solve many
>problems, even if they create others. Locking is still the main way today's
>DBMS will handle concurrency issues and avoid lost updates, for example.
>That's just the model most have used to implement transactional ACID
>properties.
I was under the impression that Oracle used optimistic locking
internally. That's not the case then? (because, like it or not, I think
Oracle is by far the most used DB right now, if we are to talk about the
"main way")
>This also shows that there are real-world problems with the EJB spec at this
>point. If there's this much confusion about locking and such with the DB,
>imagine the likelihood that a working app could really be picked up from one
>EJB container and moved to another and have it all work out. Clearly, there
>are many issues that fall back to the persistence mechanism used, and EJB
>attempts to resolve these to make portability and interoperability better.
EXACTLY! And this is the real problem here. Imagine a bean developer, or
app developer, that has to make sure that the app works both in
optimistic and pessimistic environments. It would take some serious
thinking and careful design to get it right.
So the main problem here is not how PCC and OCC are defined and their
differences and whatnot. It's the fact that we ARE discussing it in the
first place, and that it has such a huge impact on application
semantics. While this isn't strictly related to EJB (all portable apps
need to consider it), all EJB programmers are affected by it.
Food for thought.
/Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
===========================================================================
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".
