[Mulgara-dev] Lost phase token

Alex Hall alexhall at revelytix.com
Wed Sep 23 17:39:21 UTC 2009


James Leigh wrote:
> On Wed, 2009-09-23 at 12:29 -0400, Paul Gearon wrote:
>> On Wed, Sep 23, 2009 at 12:22 PM, Paul Gearon <gearon at ieee.org> wrote:
>>> So is there any chance you've done some modifications and then rolled
>>> them back rather than committing them?
>> Oops, I didn't go through the original email properly. I see that you
>> DO have a rollback (due to an exception). That's what's causing the
>> lost phase token. I'll fix that soon.
>>
>> As to what was causing your original rollback.... I need more time to
>> see what's going on there.
>>
> 
> My understanding is the the lost phase token happens before the
> OutOfMemoryException, which is before the rollback. I am using the
> mulgara-core.jar and am happy to try this out with a snapshot version.

Rollbacks can happen either implicitly (as a result of an exception
trying to execute an operation) or explicitly (by calling the
Session.rollback() method).  I think Paul's point is that in both cases,
the phase reference is not properly released.  If lots of rollbacks are
occurring over the lifetime of your application, either from explicit
rollbacks or in response to exceptions that you are ignoring, then you
could have orphaned phases accumulating that would contribute to an
OutOfMemory exception.

The OutOfMemoryException that you're seeing is thrown while handling an
implicit rollback from some error that occurred while executing an
operation.  Unfortunately that means that we're losing the original
exception that caused the rollback.

> Looking through the stacktrace, I thought this line of code looked
> suspicious(XAStatementStoreImpl.java:439):
>     if (!dirty && currentPhase.isInUse()) {
>       try {
>         new Phase();
>       } catch (IOException ex) {
>         throw new StatementStoreException("I/O error", ex);
>       }
>     }

This code does look suspicious, but the Phase inner-class constructor
sets a reference to itself in the outer XAStatementStoreImpl class.  So
the code is relying on a side-effect of something happening in the
constructor.

Regards,
Alex



More information about the Mulgara-dev mailing list