Mulgara Project: Issueshttps://code.mulgara.org/https://code.mulgara.org/favicon.ico?15861924492008-05-19T00:33:42ZMulgara Project
Redmine 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 - 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 #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 - 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> Mulgara - Bug #36 (Closed): Basic query failurehttps://code.mulgara.org/issues/362006-11-20T23:50:01Zronald -ronald@foo.bar
<pre>
<code class="html syntaxhl">The following setup demonstrates the problem:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>drop <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"local:///topazproject#test&gt;;"</span><span class="nt">></span>local:///topazproject#test<span class="ni">&amp;</span>gt;;<span class="nt"></a></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>create <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"local:///topazproject#test&gt;;"</span><span class="nt">></span>local:///topazproject#test<span class="ni">&amp;</span>gt;;<span class="nt"></a></span>
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>insert
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;</span>foo:bar<span class="ni">&gt;</span> <span class="ni">&lt;</span>foo:set<span class="ni">&gt;</span> <span class="ni">&lt;</span>user:joe<span class="ni">&gt;</span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;</span>foo:set<span class="ni">&gt;</span> <span class="ni">&lt;</span>topaz:implies<span class="ni">&gt;</span> <span class="ni">&lt;</span>bar:set<span class="ni">&gt;</span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;</span>foo:set<span class="ni">&gt;</span> <span class="ni">&lt;</span>topaz:implies<span class="ni">&gt;</span> <span class="ni">&lt;</span>bar:get<span class="ni">&gt;</span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>into <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"local:///topazproject#test&gt;;"</span><span class="nt">></span>local:///topazproject#test<span class="ni">&amp;</span>gt;;<span class="nt"></a></span>
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>select $s $p $o from <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"local:///topazproject#test"</span><span class="nt">></span>local:///topazproject#test<span class="nt"></a></span><span class="ni">&gt;</span> where (
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>$s $p $o
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>and ($s <span class="ni">&lt;</span>mulgara:is<span class="ni">&gt;</span> <span class="ni">&lt;</span>foo:bar<span class="ni">&gt;</span>)
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>) or (
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>($s $impliedBy $o and $impliedBy <span class="ni">&lt;</span>topaz:implies<span class="ni">&gt;</span> $p)
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>and ($s <span class="ni">&lt;</span>mulgara:is<span class="ni">&gt;</span> <span class="ni">&lt;</span>foo:bar<span class="ni">&gt;</span>)
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>);
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>select $s $p $o from <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"local:///topazproject#test"</span><span class="nt">></span>local:///topazproject#test<span class="nt"></a></span><span class="ni">&gt;</span> where (
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>$s $p $o
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>or ($s $impliedBy $o and $impliedBy <span class="ni">&lt;</span>topaz:implies<span class="ni">&gt;</span> $p)
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>) and ($s <span class="ni">&lt;</span>mulgara:is<span class="ni">&gt;</span> <span class="ni">&lt;</span>foo:bar<span class="ni">&gt;</span>);
<span class="nt"><br/></span>
<span class="nt"><br/></span>
The two queries are logically equivalent (the <span class="ni">&lt;</span>mulgara:is<span class="ni">&gt;</span> term is duplicated in the first query, and factored out in the second query). However, while the first query returns three statements, the second query only returns one. Specifically, the first query returns
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&lt;</span>foo:bar<span class="ni">&gt;</span> <span class="ni">&lt;</span>foo:set<span class="ni">&gt;</span> <span class="ni">&lt;</span>user:joe<span class="ni">&gt;</span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&lt;</span>foo:bar<span class="ni">&gt;</span> <span class="ni">&lt;</span>bar:set<span class="ni">&gt;</span> <span class="ni">&lt;</span>user:joe<span class="ni">&gt;</span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&lt;</span>foo:bar<span class="ni">&gt;</span> <span class="ni">&lt;</span>bar:get<span class="ni">&gt;</span> <span class="ni">&lt;</span>user:joe<span class="ni">&gt;</span>
<span class="nt"><br/></span>
<span class="nt"><br/></span>
but the second returns only
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&lt;</span>foo:bar<span class="ni">&gt;</span> <span class="ni">&lt;</span>foo:set<span class="ni">&gt;</span> <span class="ni">&lt;</span>user:joe<span class="ni">&gt;</span>
<span class="nt"><br/></span>
<span class="nt"><br/></span>
</code></pre> Mulgara - Bug #34 (Closed): NUC-disjunction fails when one term is unconstrained.https://code.mulgara.org/issues/342006-11-14T04:02:50Zronald -ronald@foo.bar
<pre>
<code class="html syntaxhl">The following is a minimal example that triggers the bug:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>create <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"local:///topazproject#test&gt;;"</span><span class="nt">></span>local:///topazproject#test<span class="ni">&amp;</span>gt;;<span class="nt"></a></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>insert
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;</span>foo:one<span class="ni">&gt;</span> <span class="ni">&lt;</span>p:type<span class="ni">&gt;</span> <span class="ni">&lt;</span>t:p<span class="ni">&gt;</span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;</span>foo:one<span class="ni">&gt;</span> <span class="ni">&lt;</span>p:hasA<span class="ni">&gt;</span> <span class="ni">&lt;</span>bar:one<span class="ni">&gt;</span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;</span>foo:one<span class="ni">&gt;</span> <span class="ni">&lt;</span>p:hasB<span class="ni">&gt;</span> 'mollusks'
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;</span>foo:two<span class="ni">&gt;</span> <span class="ni">&lt;</span>p:type<span class="ni">&gt;</span> <span class="ni">&lt;</span>t:p<span class="ni">&gt;</span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;</span>foo:two<span class="ni">&gt;</span> <span class="ni">&lt;</span>p:hasA<span class="ni">&gt;</span> <span class="ni">&lt;</span>bar:two<span class="ni">&gt;</span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;</span>foo:two<span class="ni">&gt;</span> <span class="ni">&lt;</span>p:hasB<span class="ni">&gt;</span> 'mollusks'
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>into <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"local:///topazproject#test&gt;;"</span><span class="nt">></span>local:///topazproject#test<span class="ni">&amp;</span>gt;;<span class="nt"></a></span>
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>select $a $t from <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"local:///topazproject#test"</span><span class="nt">></span>local:///topazproject#test<span class="nt"></a></span><span class="ni">&gt;</span> where
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>$b <span class="ni">&lt;</span>p:type<span class="ni">&gt;</span> <span class="ni">&lt;</span>t:p<span class="ni">&gt;</span> and
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>$b <span class="ni">&lt;</span>p:hasA<span class="ni">&gt;</span> $a and
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>(
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>($b <span class="ni">&lt;</span>p:hasB<span class="ni">&gt;</span> 'mollusks' and $t <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"http://mulgara.org/mulgara#is"</span><span class="nt">></span>http://mulgara.org/mulgara#is<span class="nt"></a></span><span class="ni">&gt;</span> '0')
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>or
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>($t <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"http://mulgara.org/mulgara#is"</span><span class="nt">></span>http://mulgara.org/mulgara#is<span class="nt"></a></span><span class="ni">&gt;</span> '1')
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>);
<span class="nt"><br/></span>
<span class="nt"><br/></span>
The result is
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>QueryException thrown in resolve:
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>org.mulgara.query.QueryException: Failed to resolve query
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>Caused by: org.mulgara.query.TuplesException: Prefix failed to meet defined minimum prefix
<span class="nt"><br/></span>
</code></pre> Mulgara - Bug #33 (Closed): can create same model twice with different typeshttps://code.mulgara.org/issues/332006-11-13T06:59:54Zronald -ronald@foo.bar
<pre>
<code class="html syntaxhl">The following is accepted by mulgara:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>create <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"local:///foo#m1&gt;;"</span><span class="nt">></span>local:///foo#m1<span class="ni">&amp;</span>gt;;<span class="nt"></a></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>create <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"local:///foo#m1"</span><span class="nt">></span>local:///foo#m1<span class="nt"></a></span><span class="ni">&gt;</span> <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"http://mulgara.org/mulgara#XMLSchemaModel&gt;;"</span><span class="nt">></span>http://mulgara.org/mulgara#XMLSchemaModel<span class="ni">&amp;</span>gt;;<span class="nt"></a></span>
<span class="nt"><br/></span>
<span class="nt"><br/></span>
This then results in a partially unusable database, as this
<span class="nt"><br/></span>
error cannot be corrected anymore. E.g.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>drop <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"local:///foo#m1&gt;;"</span><span class="nt">></span>local:///foo#m1<span class="ni">&amp;</span>gt;;<span class="nt"></a></span>
<span class="nt"><br/></span>
<span class="nt"><br/></span>
produces the error
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>Error resolving [$s $p $o $_from] from <span class="nt"><a</span> <span class="na">href=</span><span class="s">"local:///foo#m1"</span><span class="nt">></span>local:///foo#m1<span class="nt"></a></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>Model 287 has more than one type!
<span class="nt"><br/></span>
<span class="nt"><br/></span>
It would be more robust if the 'create' checked that the model type
<span class="nt"><br/></span>
is the same in the case where the model already exists.
<span class="nt"><br/></span>
</code></pre> Mulgara - Bug #19 (Closed): Fix transaction support in Mulgara to support concurrent reads and re...https://code.mulgara.org/issues/192006-09-14T04:51:02ZAndrae Muys -andrae@netymon.com
<pre>
<code class="html syntaxhl">A correct implementation of server-side JRDF requires support for concurrent reads.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Any client side round-tripping of blank-nodes requires access to read-only transactions.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
This requires refactoring (and some rewriting of) transaction support in the Session layer of Mulgara to support three-level transaction representation.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
User - We require a seperate transaction object representing a users transaction. Currently represented by a javax.transaction.Transaction object on [[DatabaseSession]]. This needs encapsulating.
<span class="nt"><br/></span>
Query - We don't currently have any concept of a transaction at the per-query level. Without this concurrent reads can't be supported.
<span class="nt"><br/></span>
Method - Currently supported via methods on [[DatabaseSession]]. These need to be lifted into a seperate manager object which can manage their interaction with query and user transactional contexts.
</code></pre> Mulgara - Bug #2 (Closed): "Multiple writers not supported" transactioning error occurs if readin...https://code.mulgara.org/issues/22006-06-27T07:28:01Zstephen.bayliss -stephen.bayliss@foo.bar
<pre>
<code class="html syntaxhl">Errors while attempting to read and write to the same model, from different iTQL sessions.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
- Repeatedly load a file containing (eg) 5000 statements in one iTQL session, for example through an iTQL script
<span class="nt"><br/></span>
- concurrently, repeatedly issue queries from another iTQL session, eg used select $s $p $o from <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"rmi://localhost/server1#tranTest"</span><span class="nt">></span>rmi://localhost/server1#tranTest<span class="nt"></a></span><span class="ni">&gt;</span> where $s $p $o limit 100;
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Periodically the following error occurs:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
2006-06-22 13:15:24,839 ERROR [[StatementStoreXAResource]] - Attempting to prepare from different transaction. Multiple writers not supported
<span class="nt"><br/></span>
<span class="nt"><br/></span>
2006-06-22 13:15:24,839 ERROR [[SubCoordinator]] - Got XAException from
<span class="nt"><br/></span>
resource.prepare: Cannot send
<span class="nt"><br/></span>
res.prepare:javax.transaction.xa.XAException (error code = -4) -null
<span class="nt"><br/></span>
</code></pre>