Hi,

currently I run into this problem while running a load test which generates
a bit unrealistic situations. I still think this problem could occur
frequently enough with normal use, too. The example consists of two beans,
Record and Artist with n:1 relationship between them. Application has quite
a lot of different view pages, displaying several combinations of data (all
records with artists / one record & it's artist / one artist & his records
/ etc etc.). At least with the server in question (WebLogic) the order
which you touch the beans determines the order which they are updated at
the end of transaction. Basically to prevent deadlocks I have to make sure:

- beans are always accessed in the same order, for example 1) artist 2)
record. A bit of unconvenience, for example when all artists are listed
with their records. "Normal" use would be

  Iterator i = artistHome.findAll().iterator();
  while (i.hasNext) {
    Artist artist = (Artist) i.next();
    domeSomethingWith(artist);
    Collection artistsRecords = artist.getRecords();
    doSomethingWith(records);
    ...

this would have to replaced with

  // first pass to touch artists

  Iterator i = artistCollection.iterator();
  while (i.hasNext) {
      Artist artist = (Artist) i.next();
      doSomethingWith(artist);
  }

  // second pass to touch records

  i = artistCollection.iterator();
  while (i.hasNext) {
      Artist artist = (Artist) i.next();
      doSomethingWith(artist.getRecords());
  }

to be exact, I don't think this is required if "finders load beans" is on
with WebLogic, but if I try to write portable code that does not help.

- Record.getArtist() could not be used at all. One would have to use
ArtistHome.findByRecordId() instead (not really classy).

Yes, I am using row level locking (Oracle).

- - -
Janne Mattila




|---------+------------------------------>
|         |           Victor Langelo     |
|         |           <[EMAIL PROTECTED]|
|         |           RVICES.COM>        |
|         |           Sent by: A mailing |
|         |           list for Enterprise|
|         |           JavaBeans          |
|         |           development        |
|         |           <[EMAIL PROTECTED]|
|         |           SUN.COM>           |
|         |                              |
|         |                              |
|         |           13.11.2003 17:10   |
|         |           Please respond to  |
|         |           Victor Langelo     |
|         |                              |
|---------+------------------------------>
  
>--------------------------------------------------------------------------------------------------------------|
  |                                                                                    
                          |
  |       To:       [EMAIL PROTECTED]                                                  
                  |
  |       cc:       (bcc: Janne Mattila/FI/TJG)                                        
                          |
  |       Subject:  Re: How to avoid database deadlocks?                               
                          |
  
>--------------------------------------------------------------------------------------------------------------|




Janne,

There are only one generic solution to avoiding your deadlock. Do all
your updates in the same order (A then B) in all threads.

Are you using row locking? If not, us it. If you are, you might look at
why you have so many concurrent updates of the same rows. Either change
your UI design or data model to avoid high contention.

--Victor


Janne Mattila wrote:

>Hi,
>
> I'm developing some BMP entity beans with WebLogic 6.1 & Oracle 9 and
>am running into lots of ORA-00060 deadlock detected errors. I know the
>cause of this, but seem to have a chicken and egg situation when
>trying to solve this...
>
>Let's say we have two entity beans, A and B, with 1:1 relationship
>between them. Both have accessor methods to each other
>
>A.getB()
>B.getA()
>
>in database one of the tables hold foreign key pointing to another's
>primary key. It's not important which one.
>
>Now, we have an application where you can view & edit both entities.
>View screen for A shows also B and vice versa. Pseudo-code for these
>view screens would be:
>
>view A:
>
>aToShow = findByPrimaryKey(primary_key_from_user)
>bToShow = a.getB()
>
>view B:
>
>bToShow = findByPrimaryKey(primary_key_from_user)
>aToShow = b.getA()
>
>Now, the problem is that WebLogic seems to call ejbStore() in the
>order in which the beans were initially accessed. Let's say thread #1
>views A and thread #2 views corresponding B. This would create
>following SQL:
>
>thread #1: UPDATE A SET...WHERE ID = 203
>thread #2: UPDATE B SET...WHERE ID = 17
>thread #1: UPDATE B SET...WHERE ID = 17 (waits for lock by #2)
>thread #2: UPDATE A SET...WHERE ID = 203 (waits for lock by #1 =>
>deadlock)
>
>Now, there could be some "hacks" around this, but the situation is not
>this simple since this occurs in much more complex situations and
>where data is actually updated. Maybe in this case some ejbSelect -methods
>could be used to reverse the order in one of the views, but this is really
>not
>practical when cases get more complex. Is there any generic way to avoid
>such
>problems while still using BMP and same data model?
>
>Interestingly enough, I do not seem to get the same problem with CMP &
>CMR. I wonder why this is the case. Still I would need to get BMP also
>working.
>
>- - -
>Janne Mattila
>
>===========================================================================

>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".
>
>

===========================================================================
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".

===========================================================================
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".

Reply via email to