----- Original Message -----
From: "Ian McCallion" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, January 27, 2001 1:30 AM
Subject: Re: [EJB-INT] Why use entity beans? (No good reason!)
> I can't help wishing that you would express your "humble" opinions more
> temperately! Perhaps then you would also notice that you don't provide
anything
> but "opinions". Pejorative expressions like those littering your post are
a sure
> sign of a weak argument.
No, they are a sign of a passionate disagreement. They are all based on real
life experience otherwise I would be Roger Sessions.
> > > 2. Locking model -
> > > a. pessimistic
> >
> > A generally looney idea IMHO - applications do not scale with
pessimistic
> > locking, we know this from basic Client/Server principles.
>
> You may "know" this but I don't. Traditional transaction processing
systems
> typically use pessimistic locking and they scale, far better that
client-server
> systems, by keeping transactions short.
Ian, I must admit not to having seen a transaction processing system that
used pessimistic locking for - maybe 10 years? A number of fundamental
reasons for this exist (in my understanding, I am sure you will correct me
if you believe I am wrong):
Pessimistic locking as I understand it is to read a record and lock it for
"write" at the same time so that unless you are in a "dirty read" mode, you
can either read or write the record. So readers are blocking other reads and
other writers. The most restrictive use of a database you can have. Right?
- TP systems share their database with other systems - such as reporting
used for EIS or DSS. The only way that TP and DSS/EIS can co-exist in a
pessimistic locking situation is to use dirty read - which is well known to
be undesirable because it provides you with inconsistent data (or am I
assuming again?). Thus if you design your TP system using pessimistic
locking you are creating questionable reports. Not exactly a good selling
point...
- If they don't share their database, they have to implement replication,
which can cause a considerable strain on the database and then you have
extra resources tied down, and out of date data and complications in
operations, and the list goes on.
- Pessimistic locking is more often than not used as a cop-out in
architectural design of an application as an easy way to make sure updates
are done correctly. Again, an opinion you say - no not quite. It is
considerably more difficult to develop an application that understands
deltas - changes to a record than to just lock it and not let anyone else
get at it. But it also makes for a more difficult to use application -
certain simple things that should be able to be done by multiple people at
the same time (such as two different people taking orders, or the same web
site wanting to update inventory or similar) are made considerably more
difficult with pessimistic locking. It just doesn't scale. Optimisitic
locking bases its mandate on the idea that a properly designed application
with a certain amount of logic to understand changes (such as two customers
placing an order at the same time and not writing an absolute credit limit)
works better than pessimistic locking under the same situation.
The list goes on and on - just pick up any text book on application design
with client/server databases and it goes into the reasons why pessimistic
locking is bad under all except the most unusual, specific circumstances.
Given that you have required me to defend my statement with what I
considered to be a statement of the obvious, I will now have to ask you to
back your statement up with a good argument why you designed your TP systems
using pessimistic locking. I base my knowledge on experience and reading,
but I am open to having that knowledge expanded upon.
Simon
===========================================================================
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".
