Hi,
isModified could work, have to check that one...separate transactions is a
big no-no. Would mess up transactional integrity.
- - -
Janne Mattila
|---------+------------------------------>
| | Victor Langelo |
| | <[EMAIL PROTECTED]|
| | RVICES.COM> |
| | Sent by: A mailing |
| | list for Enterprise|
| | JavaBeans |
| | development |
| | <[EMAIL PROTECTED]|
| | SUN.COM> |
| | |
| | |
| | 20.11.2003 19:26 |
| | Please respond to |
| | Victor Langelo |
| | |
|---------+------------------------------>
>--------------------------------------------------------------------------------------------------------------|
|
|
| To: [EMAIL PROTECTED]
|
| cc: (bcc: Janne Mattila/FI/TJG)
|
| Subject: 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 |
| | <[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".
===========================================================================
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".
