Re: How to avoid database deadlocks?

Janne,

Weblogic 5.x (the last verion I've used) supports an isModified method
for BMP. You should implement an isModified method. If they've dropped
support for calling isModified before store, simply call it yourself in
the store method. That will eliminate the db updates when there are no
changes.

In addition it would make sense to put each modification in it's own
transaction. If you must have long transactions, you'll likely have to
reorder the updates in your session bean. For instance collect the
changes and perform them at the end of each iteration.

--Victor


Janne Mattila wrote:

>Hi,
>
>on transaction delimitation; I think my original example is a bit clearer -
>the idea is that transactions are delimited by a surrounding session
>facade, for example
>
>facadeA.getData() {
>  // gets displayed data for item A and corresponding item B
>  ...
>  aToShow = findByPrimaryKey(primary_key_from_user)
>  bToShow = a.getB()
>}
>
>facadeB.getData() {
>  // gets displayed data for item B and corresponding item A
>  ...
>  bToShow = findByPrimaryKey(primary_key_from_user)
>  aToShow = b.getA()
>}
>
>The same thing with the iteration example below - so
>doSomethingWith(artist) is in the same transaction as the
>doSomethingWith(record).
>
>Why do I need updates to both tables if I am not  changing the
>relationship? Good question...the whole problem comes from the fact that
>using EJBs for the items results in updates to the tables - even when data
>has not been changed.
>
>- - -
>Janne Mattila
>
>
>
>
>|---------+------------------------------>
>|         |           Victor Langelo     |
>|         |           <vlangelo@ECLIPSESE|
>|         |           RVICES.COM>        |
>|         |           Sent by: A mailing |
>|         |           list for Enterprise|
>|         |           JavaBeans          |
>|         |           development        |
>|         |           <EJB-INTEREST@JAVA.|
>|         |           SUN.COM>           |
>|         |                              |
>|         |                              |
>|         |           18.11.2003 20:17   |
>|         |           Please respond to  |
>|         |           Victor Langelo     |
>|         |                              |
>|---------+------------------------------>
>  >--------------------------------------------------------------------------------------------------------------|
>  |                                                                                                              |
>  |       To:       [email protected]                                                                    |
>  |       cc:       (bcc: Janne Mattila/FI/TJG)                                                                  |
>  |       Subject:  Re: How to avoid database deadlocks?                                                         |
>  >--------------------------------------------------------------------------------------------------------------|
>
>
>
>
>Janne,
>
>Where are the transations delimited? I assume from your earlier post
>that doSomethingWith(artist) is not in it's own transaction. Likewise
>doSomethingWith(record) is also not in it's own transaction. Is the
>transaction the entire iteration over all artists or just one artist's
>records? In either case you're bound to have transaction deadlocks.
>
>If you're not changing the relationship between artist and record why do
>you need updates to artist and record in the same transaction?
>
>--Victor
>
>
>Janne Mattila wrote:
>
>
>
>>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
>>
>>
>>
>>
>>
>>
>
>===========================================================================
>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".