Hi,
[Thought twice before replying, given the
role of Siemens in the european software
patent conflict.]
If you do not set any transaction attributes
in your deployment descriptor for a CMT bean,
the default REQUIRED is used.
I guess you are using the Minerva wrappers
to emulate two-phase commit on a mySQL
database connection that support only
one-phase commit. Please note that this
may violate the atomicity property of
ACID transactions in case of some failures
during commit (but this is not the problem
you are experiencing here), and to avoid it
you need real XA database drivers.
If you are using the Minerva wrappers, you
may get isolation between different db
connections operating in the same transaction
since the driver does not know that both
connections are involved in the same
transaction. I think that it could also
result in a deadlock, due to database
locking. This is sometimes seen on
bean-to-bean calls when the calling bean
holds open the db connection while calling,
and the called bean opens a connection to
the same resource in the same transaction.
The workaround for this (only needed with
the Minerva wrappers) is to close the db
connection in the first bean before calling
the second bean. Behind the scene, Minerva
keeps the closed db connection open until
it can do a commit or rollback, and when the
second bean opens a connection Minerva gives
it the same connection that was used in the
first bean, and so the db really knows that
all work is done in the same transaction.
Hope this helps, otherwise mail again.
Feel free to include relevant parts of
your server log.
Best Regards,
Ole Husgaard.
Frank Marx wrote:
>
> Hi !!
>
> We fighting with a TRANSACTION ROLLBACK Problem for about two weeks now and
> would like to share our
> insights with people having a similiar problem.
>
> SITUATION:
> ==========
>
> 1. From time to time our client application hangs and doesn't react anymore
> when the application is
> executing a remote call to a EJB. This happens even though only one user
> is logged so there should not be
> any other concurrent actions going on in the system.
> Our real trouble is that we cannot reproduce this effect.
> We only see in the log files that is has something to do with
> transactions (Transaction alreay marked for rollback) and
> then "locking waiting"
>
> 2. We have defined not any transaction contexts in the EJB deployment
> descriptor, so we think JBOSS
> uses it own kind of transaction management.
>
> 3. Our Setup: mySQL and JAWS and JBOSS 2.0 running on LINUX
>
> As out next step we think about the solution of explicitly setting a
> transaction context in the deployment descriptor of the entity beans, but
> our impression is that this seems to be an internal problem of jboss.
>
> We are looking for people with ideas how else to approach this problem.
>
> Thanks in advance,
>
> Frank Marx
> Jens-Michael Lehmann
>
> TTB Siemens , Berkeley
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> List Help?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
List Help?: [EMAIL PROTECTED]
