[Mulgara-dev] Autocommit off, session abandonment and database mirroring

[Andrae Muys]

On 07/04/2007, at 4:54 AM, David Moll wrote:

> Gents,
>
>
>
> We (those of us at Viewpoint) have a question about some of the  
> documentation for Mulgara.  Specifically the part that says:
>
>
>
> If a session with autocommit set off is idle for a period greater  
> than three minutes, and a second session attempts a write, then a  
> rollback of the first session's uncommitted transactions occurs.  
> The first session's next iTQL command then reports an error  
> indicating that the transactions were lost.
>
>
>
> What does “idle” mean in this context?  We do have queries that  
> take much more than three minutes, especially deletes.  I can see  
> two possibilities.  “Idle” could mean that no new queries have  
> happened in three minutes, so the next session that sends a query  
> requiring a write lock will cause an abandonment of the first  
> session’s query.  The other possiblity is that “idle” means that  
> the metastore itself is idle, so if there is a query running which  
> takes 10 minutes to complete, it would not be in danger of being  
> abandoned until time t0 + 10 minutes + 3 minutes.

This is a concern to us, and indeed I seem to recall we extended the  
timeout for just this reason.  I was also careful to ensure that with  
the new transaction architecture that went in recently I designed in  
the ability to take full control of this timeout again at whatever  
level of granularity we require.

I expect that at some point I will update the transaction timeout  
logic to clarify the semantics.  I currently expect to define 'idle'  
as "time spent with the transaction deactivated".  As transactions  
are active during any operation on a session or answer, this would  
mean that any operation performed on the session, or any method  
called on an answer obtained while auto-commit is off would reset the  
timeout timer.  That this includes such innocuous methods as  
'getNumberOfVariables()', if you really did need to spend a  
substantial amount of time holding the lock without using it, a few  
periodic calls to such a method on an Answer would suffice to avoid a  
timeout - however this would not be required for things such as long  
queries or large loads as the transaction is active during these  
operations anyway.

Andrae

-- 
Andrae Muys
andrae at netymon.com
Principal Mulgara Consultant
Netymon Pty Ltd