[Mulgara-dev] Lost phase token

[James Leigh]

On Wed, 2009-09-23 at 15:35 -0700, Life is hard, and then you die wrote:
> On Wed, Sep 23, 2009 at 02:49:12PM -0400, Alex Hall wrote:
> > Paul Gearon wrote:
> > > On Wed, Sep 23, 2009 at 1:22 PM, Alex Hall <alexhall at revelytix.com> wrote:
> > >> James Leigh wrote:
> > >>> What else could be causing this lost phase token?
> > >> It could still be an Answer object, if you're doing explicit transaction
> > >> management by setting autocommit to false.  In that case the new phase
> > >> is created upon the first modify operation, and any subsequent query
> > >> operations made before that transaction is committed will reference that
> > >> same phase.  If you leave autocommit set to true, as is the default,
> > >> then it's correct that Answers are not going to be your culprit.
> > >>
> > >> -Alex
> > > 
> > > It's not an Answer. The stack trace shows that the phase was created
> > > when a statement was inserted. The phase can only be released during
> > > prepare/commit, so this isn't happening. The only other thing that can
> > > happen (other than prepare/commit) is a crash or a rollback. Given
> > > that he's running out of heap, then this looks to be the issue.
> > 
> > My understanding was that an Answer holds a reference to the transaction
> > in which it was created, and even if the transaction is committed the
> > Answer maintains a reference to it until it is closed. Then again there
> > are lots of subtleties to transaction management that I don't understand
> > completely, and if you've already taken the time to sort through the
> > code then I'll trust your analysis.
> 
> It's true that an Answer holds a reference to the transaction, but
> that does not prevent the transaction (if it's explicit) from being
> committed and hence the phase from being released.
> 
> Also, Paul, is it not the case that only inserts/deletes create new
> phases? I.e. when would you ever see a phase having been created by an
> Answer?
> 
> And James, are you sure you're closing all your Answer's in a timely
> fashion?
> 
> 

There process alternates between session.modelExists(model) and
session.insert(model, Collections.singleton(st)) and sometimes a delete.
So this alternating between read and write is causing all these phase
tokens to be created. Because modelExists, insert, delete do not return
any Answers there is nothing to be closed.

Here is the stack to to a use() call that is never released. It looks
like this delete is causing the problems.

Any thoughts?

James
---

  org.mulgara.store.xa.FreeList$Phase.use(FreeList.java:1138)
  org.mulgara.store.xa.ManagedBlockFile$Phase$Token.<init>(ManagedBlockFile.java:528)
  org.mulgara.store.xa.ManagedBlockFile$Phase.use(ManagedBlockFile.java:288)
  org.mulgara.store.xa.AVLFile$Phase$Token.<init>(AVLFile.java:457)
  org.mulgara.store.xa.AVLFile$Phase.use(AVLFile.java:393)
  org.mulgara.store.statement.xa.TripleAVLFile$Phase$Token.<init>(TripleAVLFile.java:1673)
  org.mulgara.store.statement.xa.TripleAVLFile$Phase.use(TripleAVLFile.java:1419)
  org.mulgara.store.statement.xa.TripleAVLFile$Phase$AbstractStoreTuples.<init>(TripleAVLFile.java:1805)
  org.mulgara.store.statement.xa.TripleAVLFile$Phase$TuplesImpl.<init>(TripleAVLFile.java:2273)
  org.mulgara.store.statement.xa.TripleAVLFile$Phase.allTuples(TripleAVLFile.java:1227)
  org.mulgara.store.statement.xa.XAStatementStoreImpl$Phase.findTuples(XAStatementStoreImpl.java:1853)
  org.mulgara.store.statement.xa.XAStatementStoreImpl.findTuples(XAStatementStoreImpl.java:589)
  org.mulgara.resolver.store.StatementStoreResolution.defineIndex(StatementStoreResolution.java:264)
  org.mulgara.resolver.store.StatementStoreResolution.<init>(StatementStoreResolution.java:154)
  org.mulgara.resolver.store.StatementStoreResolver.resolve(StatementStoreResolver.java:393)
  org.mulgara.resolver.InternalResolver.resolve(InternalResolver.java:180)
  org.mulgara.resolver.DatabaseOperationContext.resolveVariableGraph(DatabaseOperationContext.java:696)
  org.mulgara.resolver.DatabaseOperationContext.resolve(DatabaseOperationContext.java:620)
  org.mulgara.resolver.LocalQueryResolver.resolve(LocalQueryResolver.java:187)
  org.mulgara.resolver.DefaultConstraintHandlers$11.resolve(DefaultConstraintHandlers.java:244)
  org.mulgara.resolver.ConstraintOperations.resolveConstraintExpression(ConstraintOperations.java:187)
  org.mulgara.resolver.LocalQueryResolver.resolveConstraintOperation(LocalQueryResolver.java:112)
  org.mulgara.resolver.DefaultConstraintHandlers$5.resolve(DefaultConstraintHandlers.java:162)
  org.mulgara.resolver.ConstraintOperations.resolveConstraintExpression(ConstraintOperations.java:187)
  org.mulgara.resolver.LocalQueryResolver.resolveE(LocalQueryResolver.java:269)
  org.mulgara.resolver.DatabaseOperationContext.doQuery(DatabaseOperationContext.java:794)
  org.mulgara.resolver.ModifyGraphOperation.execute(ModifyGraphOperation.java:179)
  org.mulgara.resolver.MulgaraInternalTransaction.execute(MulgaraInternalTransaction.java:625)
  org.mulgara.resolver.DatabaseSession.execute(DatabaseSession.java:751)
  org.mulgara.resolver.DatabaseSession.modify(DatabaseSession.java:737)
  org.mulgara.resolver.DatabaseSession.delete(DatabaseSession.java:353)