Project

General

Profile

Bug #48

update results incorrect when autocommit on and multiple sessions are used

Added by ronald - almost 16 years ago. Updated over 15 years ago.

Status:
Closed
Priority:
Urgent
Assignee:
Category:
Mulgara
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Resolution:
fixed

Description

The following sequence illustrates the problem:
<br/>

<br/>
&nbsp;&nbsp;In first db session:
<br/>

<br/>
&nbsp;&nbsp;&nbsp;&nbsp;insert &lt;a:foo&gt; &lt;a:bar&gt; 'hi' into &lt;<a href="local:///topazproject#foo">local:///topazproject#foo</a>&gt; ;
<br/>
&nbsp;&nbsp;&nbsp;&nbsp;insert &lt;a:foo&gt; &lt;a:bar&gt; 'bye' into &lt;<a href="local:///topazproject#foo">local:///topazproject#foo</a>&gt; ;
<br/>
&nbsp;&nbsp;&nbsp;&nbsp;delete select $s &lt;a:bar&gt; $o from &lt;<a href="local:///topazproject#foo">local:///topazproject#foo</a>&gt; where $s &lt;a:bar&gt; $o from &lt;<a href="local:///topazproject#foo">local:///topazproject#foo</a>&gt; ;
<br/>
&nbsp;&nbsp;&nbsp;&nbsp;insert &lt;a:foo&gt; &lt;a:bar&gt; 'blah' into &lt;<a href="local:///topazproject#foo">local:///topazproject#foo</a>&gt; ;
<br/>

<br/>
&nbsp;&nbsp;Then in second db session:
<br/>

<br/>
&nbsp;&nbsp;&nbsp;&nbsp;select $s &lt;a:bar&gt; $o from &lt;<a href="local:///topazproject#foo">local:///topazproject#foo</a>&gt; where $s &lt;a:bar&gt; $o ;
<br/>

<br/>
The final select should return a single result:
<br/>

<br/>
&nbsp;&nbsp;&nbsp;&nbsp;a:foo a:bar &quot;blah&quot;
<br/>

<br/>
but really returns
<br/>

<br/>
&nbsp;&nbsp;&nbsp;&nbsp;a:foo a:bar &quot;blah&quot;
<br/>
&nbsp;&nbsp;&nbsp;&nbsp;a:foo a:bar &quot;hi&quot;
<br/>
&nbsp;&nbsp;&nbsp;&nbsp;a:foo a:bar &quot;bye&quot;
<br/>

<br/>
If the 'delete select' or the last 'insert' is followed by a 'set
<br/>
autocommit on' then the result is correct. Also, if the query is done
<br/>
in the same db session then the result is correct.
<br/>

<br/>
I'm attaching two patches. The first actually does three things:
<br/>

<br/>
&nbsp;- it adds a log message when the [[TransactionalAnswer]] is cloned so
<br/>
&nbsp;&nbsp;&nbsp;that all instance creations are logged (this bug was leading to
<br/>
&nbsp;&nbsp;&nbsp;'TransactionalAnswer not closed' warnings for these cloned
<br/>
&nbsp;&nbsp;&nbsp;instances)
<br/>

<br/>
&nbsp;- it makes sure the query answer in a 'delete select' or 'insert
<br/>
&nbsp;&nbsp;&nbsp;select' is properly closed.
<br/>

<br/>
&nbsp;- it makes sure the query answers are properly closed in
<br/>
&nbsp;&nbsp;&nbsp;RelationalResolution - I noticed these while searching the code
<br/>
&nbsp;&nbsp;&nbsp;for other [[LocalizedTuples]] usage after finding the above problem.
<br/>

<br/>
The second patch is a test case for this problem: it fails with stock
<br/>
rev <a href="http://mulgara.org/trac/changeset/192">192</a>, but that succeeds with the first patch applied.
<br/>

<br/>
I'm not 100% convinced that the first patch is the true solution, but
<br/>
it does fix numerous 'TransactionalAnswer not closed' warnings and
<br/>
does seem to work. I.e. I think it should probably be applied, but
<br/>
something else is probably also needed.
<br/>

#1

Updated by Andrae Muys - over 15 years ago

This is due to the stale answers holding open the transaction.  There are two solutions to this, both are required.
<br/>

<br/>
1) Close stale answers so the transaction is closed properly.
<br/>

<br/>
2) Detect the existence of an uncommitted transaction that has leaked and commit it while emitting the appropriate ERROR log message.
#2

Updated by Andrae Muys - over 15 years ago

Fixed in revision <a href="http://mulgara.org/trac/changeset/208">208</a>

Also available in: Atom PDF