Mulgara Project: Issueshttps://code.mulgara.org/https://code.mulgara.org/favicon.ico?15861924492008-05-19T00:38:16ZMulgara Project
Redmine Mulgara - Feature #122 (Closed): Support XAResource.setTransactionTimeouthttps://code.mulgara.org/issues/1222008-05-19T00:38:16Zronald -ronald@foo.bar
<p><code>MulgaraXAResource</code> currently ignores the timeout and returns false. Instead<br />it should set the underlying transaction timeout.</p>
<p>This depends on <a class="issue tracker-9 status-27 priority-27 priority-high3 closed" title="Feature: Abort idle transactions on timeout (Closed)" href="https://code.mulgara.org/issues/121">#121</a> for complete functionality.</p> Mulgara - Feature #121 (Closed): Abort idle transactions on timeouthttps://code.mulgara.org/issues/1212008-05-19T00:33:42Zronald -ronald@foo.bar
<p>If a client goes away while holding the write lock, the write lock is<br />never released, leading to mulgara being locked forever. Currently the<br />timeout "only" sets the timeout on the internal transaction manager<br />which just causes the transaction to be marked for rollback on a<br />timeout. However, setting the timeout should also start a timer which<br />is used to abort a non-active transaction (this should happened for<br />both read-write as well as read-only transactions as the latter could<br />be holding on to a phase, leading to a "memory leak").</p> Mulgara - Bug #101 (Closed): Explicit rollback throws exception if called after implicit rollback.https://code.mulgara.org/issues/1012008-04-18T14:30:29ZAndrae Muys -andrae@netymon.com
<pre>
setAutoCommit(false)
query(corrupt-query); - triggers rollback.
rollback();
</pre><br />throws exception (attempt to reserveWriteLock without write-lock).
<p>should be a nop.</p> Mulgara - Bug #100 (Closed): Closing Answer from implicit transaction closes subsequent explicit ...https://code.mulgara.org/issues/1002008-04-18T02:12:59ZAndrae Muys -andrae@netymon.com
<p>setAutoCommit(true);<br />query() -> answer<br />setAutoCommit(false);<br />query.close();<br />commit();<br />setAutoCommit(true);</p>
<p>The commit fails to reserve the writeLock complaining that the writeLock has already been released.</p>
<p>Test case duplicating bug has been added to <a class="wiki-page new" href="https://code.mulgara.org/projects/mulgara/wiki/AdvDatabaseSessionUnitTest">AdvDatabaseSessionUnitTest</a>.</p> Mulgara - Bug #98 (Closed): Backups failing Mulgara 1.2 Windowshttps://code.mulgara.org/issues/982008-04-16T18:03:01Zben hysell -benh@viewpointusa.com
<p>Backups are failing on Windows Systems.</p>
<p>Patch has been extracted and needs to be evaluated and applied to trunk.</p> Mulgara - Bug #85 (Closed): Merge JTA Branch into trunkhttps://code.mulgara.org/issues/852008-03-08T02:16:01ZAndrae Muys -andrae@netymon.com
<p>Merge JTA Branch into trunk</p> Mulgara - Feature #84 (Closed): Review and Test JTA Branchhttps://code.mulgara.org/issues/842008-03-08T02:13:58ZAndrae Muys -andrae@netymon.com
<p>Code-review and testing for the JTA Implementation</p> Mulgara - Feature #73 (Closed): Provide access to Mulgara's transaction api via a JTA XAResource ...https://code.mulgara.org/issues/732007-10-16T04:33:26ZAndrae Muys -andrae@netymon.com
<pre>
<code class="html syntaxhl">Provide a JTA XAResource that provides access to Mulgara transactions - this will permit Mulgara to participate in externally mediated distributed transactions. So this would permit mulgara transactions to be synchronised with mysql/postgres/J2EE transactions.
</code></pre> Mulgara - Bug #70 (Closed): Using a database-session in multiple threads can deadlock the serverhttps://code.mulgara.org/issues/702007-09-11T10:56:51Zronald -ronald@foo.bar
<pre>
<code class="html syntaxhl">We have a shutdown handler on the client that closes open sessions;
<span class="nt"><br/></span>
however, this shutdown handler is run is separate thread of its own.
<span class="nt"><br/></span>
So an abort of the client while it's doing a db operation can generate
<span class="nt"><br/></span>
the following sequence of events which leads to a deadlock:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
{noformat}
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>Thread-1 Thread-2
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>set autocommit off
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>...
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>insert ... close()
<span class="nt"><br/></span>
{noformat}
<span class="nt"><br/></span>
<span class="nt"><br/></span>
(i.e. the insert and the close happen almost simultaneously). The
<span class="nt"><br/></span>
resulting stack traces are roughly:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
{noformat}
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>Thread-1:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>DatabaseSession.insert()
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>DatabaseSession.execute()
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>MulgaraTransaxction.execute()
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>MulgaraTransaction.deactivate() <span class="ni">&lt;</span>---- monitor held
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>MulgaraTransaction.commitTransation()
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>MulgaraTransactionManager.transacactionComplete()
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>MulgaraTransactionManager.acquireMutex() <span class="ni">&lt;</span>--- blocked
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>Thread-2:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>DatabaseSession.close()
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>MulgaraTransactionManager.rollbackCurrentTransactions()
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>MulgaraTransactionManager.acquireMutex() <span class="ni">&lt;</span>--- mutex held
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>MulgaraTransaction.execute()
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>MulgaraTransaction.activate() <span class="ni">&lt;</span>--- blocked
<span class="nt"><br/></span>
{noformat}
<span class="nt"><br/></span>
<span class="nt"><br/></span>
</code></pre> Mulgara - Feature #69 (Closed): Refactor LocalQuery to clean up call pathshttps://code.mulgara.org/issues/692007-09-10T06:07:19ZAndrae Muys -andrae@netymon.com
<pre>
<code class="html syntaxhl">Rationalise the multiple calls to resolve(); rename class [[QueryEvalContext]] or similar and likewise rename [[LocalQueryResolver]] to match. Clean-up to make class more stateless, and consequently to eliminate some of the encapsulation hacks in LQR.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
This will make the model-name fix much cleaner - as well as making it possible to improve the Resolver and Custom-Constraint SPI's.
</code></pre> Mulgara - Bug #48 (Closed): update results incorrect when autocommit on and multiple sessions are...https://code.mulgara.org/issues/482007-02-28T04:02:05Zronald -ronald@foo.bar
<pre>
<code class="html syntaxhl">The following sequence illustrates the problem:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>In first db session:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>insert <span class="ni">&lt;</span>a:foo<span class="ni">&gt;</span> <span class="ni">&lt;</span>a:bar<span class="ni">&gt;</span> 'hi' into <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"local:///topazproject#foo"</span><span class="nt">></span>local:///topazproject#foo<span class="nt"></a></span><span class="ni">&gt;</span> ;
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>insert <span class="ni">&lt;</span>a:foo<span class="ni">&gt;</span> <span class="ni">&lt;</span>a:bar<span class="ni">&gt;</span> 'bye' into <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"local:///topazproject#foo"</span><span class="nt">></span>local:///topazproject#foo<span class="nt"></a></span><span class="ni">&gt;</span> ;
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>delete select $s <span class="ni">&lt;</span>a:bar<span class="ni">&gt;</span> $o from <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"local:///topazproject#foo"</span><span class="nt">></span>local:///topazproject#foo<span class="nt"></a></span><span class="ni">&gt;</span> where $s <span class="ni">&lt;</span>a:bar<span class="ni">&gt;</span> $o from <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"local:///topazproject#foo"</span><span class="nt">></span>local:///topazproject#foo<span class="nt"></a></span><span class="ni">&gt;</span> ;
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>insert <span class="ni">&lt;</span>a:foo<span class="ni">&gt;</span> <span class="ni">&lt;</span>a:bar<span class="ni">&gt;</span> 'blah' into <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"local:///topazproject#foo"</span><span class="nt">></span>local:///topazproject#foo<span class="nt"></a></span><span class="ni">&gt;</span> ;
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>Then in second db session:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>select $s <span class="ni">&lt;</span>a:bar<span class="ni">&gt;</span> $o from <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"local:///topazproject#foo"</span><span class="nt">></span>local:///topazproject#foo<span class="nt"></a></span><span class="ni">&gt;</span> where $s <span class="ni">&lt;</span>a:bar<span class="ni">&gt;</span> $o ;
<span class="nt"><br/></span>
<span class="nt"><br/></span>
The final select should return a single result:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>a:foo a:bar <span class="ni">&quot;</span>blah<span class="ni">&quot;</span>
<span class="nt"><br/></span>
<span class="nt"><br/></span>
but really returns
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>a:foo a:bar <span class="ni">&quot;</span>blah<span class="ni">&quot;</span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>a:foo a:bar <span class="ni">&quot;</span>hi<span class="ni">&quot;</span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>a:foo a:bar <span class="ni">&quot;</span>bye<span class="ni">&quot;</span>
<span class="nt"><br/></span>
<span class="nt"><br/></span>
If the 'delete select' or the last 'insert' is followed by a 'set
<span class="nt"><br/></span>
autocommit on' then the result is correct. Also, if the query is done
<span class="nt"><br/></span>
in the same db session then the result is correct.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
I'm attaching two patches. The first actually does three things:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;</span>- it adds a log message when the [[TransactionalAnswer]] is cloned so
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;</span>that all instance creations are logged (this bug was leading to
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;</span>'TransactionalAnswer not closed' warnings for these cloned
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;</span>instances)
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;</span>- it makes sure the query answer in a 'delete select' or 'insert
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;</span>select' is properly closed.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;</span>- it makes sure the query answers are properly closed in
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;</span>RelationalResolution - I noticed these while searching the code
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;</span>for other [[LocalizedTuples]] usage after finding the above problem.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
The second patch is a test case for this problem: it fails with stock
<span class="nt"><br/></span>
rev <span class="nt"><a</span> <span class="na">href=</span><span class="s">"http://mulgara.org/trac/changeset/192"</span><span class="nt">></span>192<span class="nt"></a></span>, but that succeeds with the first patch applied.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
I'm not 100% convinced that the first patch is the true solution, but
<span class="nt"><br/></span>
it does fix numerous 'TransactionalAnswer not closed' warnings and
<span class="nt"><br/></span>
does seem to work. I.e. I think it should probably be applied, but
<span class="nt"><br/></span>
something else is probably also needed.
<span class="nt"><br/></span>
</code></pre> Mulgara - Bug #46 (Closed): Track down and resolve Lost-Phase Tokenshttps://code.mulgara.org/issues/462007-02-26T03:52:55ZAndrae Muys -andrae@netymon.com
<pre>
<code class="html syntaxhl">Lost-phase tokens lead to resource leaks - as an ongoing concern we need to track down and resolve any lost-phase tokens noticed in the course of normal execution.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Lost-phase tokens are the result of Tuples objects not being closed properly - this is generally due to a call to clone() without a subsequent call to close() on *both* tuples.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Tracking this down is then a case of figuring out where the guilty tuples object was created, and then identifying where it should have been closed.
</code></pre> Mulgara - Bug #44 (Closed): Error during transaction.commit() causes infinite recursion and loopinghttps://code.mulgara.org/issues/442007-02-25T09:13:24Zronald -ronald@foo.bar
<pre>
<code class="html syntaxhl">This is svn head (rev <span class="nt"><a</span> <span class="na">href=</span><span class="s">"http://mulgara.org/trac/changeset/189"</span><span class="nt">></span>189<span class="nt"></a></span>), i.e. with the new transaction code.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Here's a small snippet of the stack when the error is triggered:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>at org.objectweb.jotm.TransactionImpl.commit(TransactionImpl.java:222)
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>at org.mulgara.resolver.MulgaraTransaction.terminateTransaction(MulgaraTransaction.java:330)
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>at org.mulgara.resolver.MulgaraTransaction.deactivate(MulgaraTransaction.java:154)
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>at org.mulgara.resolver.MulgaraTransaction.execute(MulgaraTransaction.java:207)
<span class="nt"><br/></span>
<span class="nt"><br/></span>
If commit() throws an exception, implicitRollback() will be invoked at
<span class="nt"><br/></span>
line 333, which in turn call checkActivated() on line 262, which in
<span class="nt"><br/></span>
turn calls implicitRollback() on line 442 because inuse is 0 (from
<span class="nt"><br/></span>
deactivate()).
<span class="nt"><br/></span>
<span class="nt"><br/></span>
At this point things go horribly wrong...
<span class="nt"><br/></span>
<span class="nt"><br/></span>
An easy way to trigger this is run out of disk space where the db
<span class="nt"><br/></span>
resides (e.g. on linux create a fs on a small file and mount using the
<span class="nt"><br/></span>
loop device: 'dd if=/dev/zero of=/tmp/mdb bs=4096 count=1000',
<span class="nt"><br/></span>
'mke2fs /tmp/mdb', 'mount -o loop /tmp/mdb /mnt/disk').
<span class="nt"><br/></span>
<span class="nt"><br/></span>
</code></pre> Mulgara - Bug #38 (Closed): starting transaction does not create a sessionhttps://code.mulgara.org/issues/382006-12-04T18:35:45Zalexcozzi -alexcozzi@foo.bar
<pre>
<code class="html syntaxhl">The following code causes a null pointer exception at the <span class="ni">&quot;&quot;</span>beginTransaction<span class="ni">&quot;</span> command.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
[[ItqlInterpreterBean]] bean = new [[ItqlInterpreterBean]]();
<span class="nt"><br/></span>
String insertText = <span class="ni">&quot;</span>insert <span class="ni">&lt;</span>urn:alex<span class="ni">&gt;</span> <span class="ni">&lt;</span>urn:name<span class="ni">&gt;</span> 'alex cozzi' into <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"rmi://localhost/server1#sampledata&gt;;"</span><span class="nt">></span>rmi://localhost/server1#sampledata<span class="ni">&amp;</span>gt;;<span class="nt"></a></span><span class="ni">&quot;</span>;
<span class="nt"><br/></span>
bean.beginTransaction(<span class="ni">&quot;</span>insertion<span class="ni">&quot;</span>);
<span class="nt"><br/></span>
bean.executeUpdate(insertText);
<span class="nt"><br/></span>
bean.commit(<span class="ni">&quot;</span>insertion<span class="ni">&quot;</span>);
<span class="nt"><br/></span>
<span class="nt"><br/></span>
If I use the bean before calling beginTransaction then everything is fine. Another workaound is to use
<span class="nt"><br/></span>
bean.setServerURI(<span class="ni">&quot;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"rmi://localhost/server1"</span><span class="nt">></span>rmi://localhost/server1<span class="nt"></a></span><span class="ni">&quot;</span>);
<span class="nt"><br/></span>
before calling beginTransaction.
</code></pre> Mulgara - Feature #37 (Closed): Lock-splitting required for MulgaraTransactionManagerhttps://code.mulgara.org/issues/372006-12-04T05:15:18ZAndrae Muys -andrae@netymon.com
<pre>
<code class="html syntaxhl">While documenting the new transaction work I noticed that the read-only and read-write paths through the Manager share the came lock - the manager just uses synchronized methods (ie. is a monitor).
<span class="nt"><br/></span>
<span class="nt"><br/></span>
As read-write transactions can block for a substantial duration during a commit, while the block-cache is flushed to disk, they should not hold the same lock as the read-only methods require to initate read-transactions while this is happening.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
The solution is to introduce two locks independent of the manager's monitor lock.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
1. Covering alterations to the transaction metadata held in the manager, all of which are simple O(1) operations.
<span class="nt"><br/></span>
2. Covering alterations to the write-lock/writing-session metadata, which must be held over a commit().
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Deadlock is not possible as the 2nd lock is only obtained by sessions wishing to obtain the writelock.
<span class="nt"><br/></span>
</code></pre>