As I have stated elsewhere, if you have optimistic concurrency there is no
possibility of deadlock. Unfortunately, we have to get into the definitions of
optimistic vs pessimistic concurrency control. That is the problem you're having
with what I am saying. The situation you describe is what I originally referred
to as a hybrid. You're attempting to implement optimistic concurrency on top of
a database that uses pessimistic locking. In this case, you're right, careful
application design is required.
It's possible to implement any of the transaction isolation levels defined in
JDBC and EJB 1.0 with either optimistic or pessimistic concurrency control. The
difference between levels is in how a conflict is defined. That's not to say
it's going to be easy with optimistic concurrency control.
--Victor Langelo
"Lahooti, Hamid" wrote:
> Victor
> I don't know about David but I wasn't talking about a hybrid policy.
> Lets go back to basics but please, no more definitions of optimistic
> Vs pessimistic locking.
> The question raised on this thread was whether we can eliminate the
> possibility of deadlock at database resource level by using optimistic
> locking.
>
> Consider the case of two applications updating entity beans A and B.
> Lets say both applications demarcate TX1 and TX2 transactions at session
> bean level and that each transaction encompasses updates to both A and B.
>
> The containers can have 2 different policies here: either serialise access
> to the entity beans (e.g. WebLogic) or rely on the resource manager to
> provide the transaction isolation (e.g. WebSphere). In the latter case,
> there is potential for deadlock. Of course the resource manager will detect
> the deadlock after a timeout and choose one of the transactions as a victim
> for rollback.
>
> Regards,
> Hamid
> -----Original Message-----
> From: Victor Langelo [mailto:[EMAIL PROTECTED]]
> Sent: 27 July 2000 15:11
> To: [EMAIL PROTECTED]
> Subject: Re: EBs are slow (was Clustering)
>
> David and Hamid,
>
> You both seem to be talking about some sort of hybrid of optimistic and
> pessimistic locking. Maybe that is from experience with actual EJB servers
> and
> DBMS.
>
> Rickard's description of optimistic and pessimistic locking is correct in
> the
> computer science sense. I won't get into what happens with real products.
> These
> are two different approaches to handling resource contention.
>
> To restate, pure optimistic locking checks for conflicts at transaction
> commit.
> Pessimistic locking "locks" resources during a transaction so other
> concurrent
> transactions cannot change/access those resources until the controlling
> transaction completes. There are, of course, many shades and variations on
> both
> of these schemes. And we can argure the merrits of each endlessly.
>
> So if you're talking about pure optimistic locking and not some hybrid, then
> there is no possibility of deadlocks. You'll only get transaction rollbacks
> due
> to conflicts.
>
> --Victor Langelo
===========================================================================
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".
