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 |
| | <[EMAIL PROTECTED]|
| | RVICES.COM> |
| | Sent by: A mailing |
| | list for Enterprise|
| | JavaBeans |
| | development |
| | <[EMAIL PROTECTED]|
| | 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".
