geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Jencks (JIRA)" <>
Subject [jira] Updated: (GERONIMO-1004) SequenceTablePrimaryKeyGenerator transaction handling is broken (Tranql)
Date Tue, 13 Sep 2005 01:02:31 GMT
     [ ]

David Jencks updated GERONIMO-1004:

    Attachment: pkgenerator.diff

Patch intended for openejb, and it is not my code:

This issue should probably be at tranql and/or openejb, but it is here.  I have a solution
that works, but it involves moving code from tranql to openejb.  I've attached the patch to
 that moves the code, and I'm assigning it to the tranql code's author.

Gianny, can you comment on this issue whether you are OK with moving the code to openejb,
if so I will commit it. (or you can if you prefer)

The basic idea is to use a TransactionPolicy interceptor to suspend the current transaction
and get a connection within "no transaction".  If our interceptors supported setting tx isolation
we could use the RequiresNew tx policy.

david jencks

> SequenceTablePrimaryKeyGenerator transaction handling is broken (Tranql)
> ------------------------------------------------------------------------
>          Key: GERONIMO-1004
>          URL:
>      Project: Geronimo
>         Type: Bug
>   Components: transaction manager
>     Versions: 1.0-M5
>     Reporter: David Jencks
>     Assignee: David Jencks
>      Fix For: 1.0-M5
>  Attachments: pkgenerator.diff
> Tranql's SequenceTablePrimaryKeyGenerator thinks it is doing its work in a new transaction,
but it is not.  It breaks the current transaction, and fails if you are using an xa datasource.
> The current openejb setup code does not allow for passing a separate ds in for the pk
generator than for cmp.  Therefore it appears that essentially doing a "requires new" call
is best.  However, the transaction module classes are not available in tranql since transaction
depends on tranql (using a cache class).   I think moving the SequenceTable pk generator to
openejb is the most practical short term solution but I will look for others.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message