Simon Blake wrote:
>
> 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):
Want me to do your research for you eh? :-) (Sorry, couldn't resist)
> 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?
Yes, other readers or writers of the same record are blocked between the
read-for-update and the end of the transaction. But no it's not the most
restrictive use of a database you can have. The most restrictive prevents
insertion or deletion into the entire table also in order to ensure "repeatable
read". http://www.google.com/search?q=repeatable+read. Short ACID transactions
http://www.google.com/search?q=acid+transaction+properties&hl=en&lr=&safe=off&btnG=Google+Search
that lock only the records used by a transaction give the needed consistency
and thruput for most transactional applications.
> - 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.
In large systems, EISs DO usually operate on out-of-date data - stable end of
day, week, month or year data is actually more useful for reporting and trend
analysis than the online, changing copy of the data. That's why "data
warehousing" was developed. And no, taking these periodic copies adds no load
whatsoever to the online system because they are (or can be) constructed from
the logs generated by the online system.
> - 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.
I don't disagree with any of the above, but you are talking about
pessimistic/optimistic locks held for the time that the user is working with a
set of data whereas I have been talk about locks held for the duration of a
transaction and these are not necessarily the same times. This is the crux...
The traditional client server application design pattern uses (long) optimistic
locking transactions to coordinate both the user interactions and the database
updates. However the traditional application server design pattern uses (short)
pessimistic locking transactions for coordinating database updates and a
different construct, sessions, to coordinate the user interactions. The client
server pattern can be successfully used on application servers. The advantages
of using the application server pattern are:
1. It reduces the per-user resources needed hence makes the application
more scaleable.
2. It uses the application server in the way it was designed to be used
hence probably makes the application more reliable.
3. There are some functional advantages as well. Applications can
sometimes exploit the fact that a failure during a session does
not automatically role back all database changes to improve the
end-user experience.
So in a sense we were both right!
Ian McCallion
Alexis Systems Limited
Romsey, UK
===========================================================================
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".
