> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of James
> Cook
> Sent: Monday, May 07, 2001 5:54 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] TODO: JBossCMP 1.1 FAST!
>
>
> ----- Original Message -----
> From: "Bill Burke" <[EMAIL PROTECTED]>
>
> > The point I'm trying to make is that with CMPs current state,
> we should not
> > be encouraging people to have tuned-updates turned off because they will
> > most certainly run into deadlock problems if they have more than one
> > concurrent user.
>
> I don't see how this can deadlock? There are concurrency issues
> with any update
> to the database, tuned or not. How is a deadlock possible?
>
It's very easy to get deadlock.
Table Apple:
apple_prim_key Number
apple_data1 varchar(256)
apple_data2 Number
Table Pear:
pear_prim_key Number
pear_apple_id Number (indexed/secondary key constraint to Apple table. Not
sure of the correct term here).
I have 2 threads, each running in their own transaction, each working with
totaly different rows from the same tables in an Oracle 8.1.6 DB.
1. Thread 1 does a AppleHome.findByPrimaryKey obtaining an Apple Entity
Bean.
2. Thread 1 calls a set attribute on the Apple entity bean. CMP loads and
locks the EntityBean. Since a field is changed, this bean will also be
updated when the transaction commits.
3. Thread 2 does a AppleHome.findByPrimaryKey for a different Apple Entity
Bean and sets an attribute on it as well.
4. Thread 1 inserts a Pear into the database. This causes a shared-lock on
the secondary key index/constraint for the entire apple table.
5. Thread 2 inserts a Pear into the database. Causes a shared-lock.
6. Thread 1 finishes and is trying to commit. CMP updates the entire Apple
including the primary key. Since a primary key is being updated on an
Apple, the database needs to obtain an exclusive-lock on the secondary
key/index constraint. It can't obtain an exclusive-lock because thread 2
has a shared-lock on the secondary key index/constraint, so it waits.
7. Thread 2 finishes and does the same logic as in step 6. It waits for
Thread 1 because Thread 1 has a shared-lock on the index.
DEADLOCK! Remember, Thread 1 and Thread 2 are accessing totally different
Entity beans! This simple scenario is why updating primary keys is very
very bad.
Because of RTFM problems and because tuned-updates used to be false by
default, we almost trashed JBoss because we were getting deadlock in very
simple code.
Regards,
Bill
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
