Mulgara Project: Issueshttps://code.mulgara.org/https://code.mulgara.org/favicon.ico?15861924492008-04-18T14:30:29ZMulgara Project
Redmine 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 - Feature #92 (Closed): Replace JRDF as an internal API for Mulgara with our own represen...https://code.mulgara.org/issues/922008-03-26T05:13:11ZAndrae Muys -andrae@netymon.com
<p>We should continue to provide support for JRDF as an external client API, but we should move to our own set of interfaces for handling RDF values internally.</p>
<p>Downdside: This will not be a backwards compatible change to things like the Resolver API; and this will also involve changing <strong>alot</strong> of interfaces inside Mulgara.</p> Mulgara - Bug #89 (Closed): Track down problems with BackupOperationhttps://code.mulgara.org/issues/892008-03-20T01:36:30ZAndrae Muys -andrae@netymon.com
<p>Viewpoint is reporting duplicate <a class="wiki-page new" href="https://code.mulgara.org/projects/mulgara/wiki/StringPool">StringPool</a> entries, as well as the introduction of blank-nodes in backups.</p>
<p>Topaz is reporting NPE's when trying to run backups on the committed-phase.</p>
<p>We need to identify the bug, and fix it.</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 - Bug #81 (In Progress): Blank Node Assignment in Inserts inconsistent with autocommithttps://code.mulgara.org/issues/812008-02-28T06:23:04ZAndrae Muys -andrae@netymon.com
<p>It appears that the binding of variables to blank nodes when inserting <br />statements behaves differently depending on whether autocommit is turned <br />on for the session. If I have autocommit turned on and execute the <br />following iTQL commands:<br /><pre>
create <rmi://localhost/server1#test>;
insert <test:subj> <test:pred> $x $x <test:value> 'o1'
into <rmi://localhost/server1#test> ;
insert <test:subj> <test:pred> $x $x <test:value> 'o2'
into <rmi://localhost/server1#test> ;
select $s $p $o from <rmi://localhost/server1#test> where $s $p $o;
</pre><br />Then I see that the variable "x" is bound to different blank nodes in <br />each of the two insertions, and the resulting model has 4 statements. <br />This is the behavior (behaviour?) that I would expect.</p>
<p>However, when I turn autocommit off prior to the first insertion, and <br />turn it back on after the second insertion, then I see that the variable <br />"x" is bound to the <strong>same</strong> blank node in each of the insertions, <br />resulting in 3 total statements in the model, which came as a bit of a <br />surprise to me. Is this the expected behavior in that situation?</p> Mulgara - Bug #58 (Closed): Model Name URI/URL Disambiguationhttps://code.mulgara.org/issues/582007-04-19T06:08:31ZAndrae Muys -andrae@netymon.com
<pre>
<code class="html syntaxhl">Reimplement the fix for <span class="nt"><a</span> <span class="na">href=</span><span class="s">"http://sourceforge.net/tracker/index.php?func=detail&aid=1316065&group_id=89874&atid=591704"</span><span class="nt">></span>http://sourceforge.net/tracker/index.php?func=detail<span class="ni">&amp;</span>aid=1316065<span class="ni">&amp;</span>group_id=89874<span class="ni">&amp;</span>atid=591704<span class="nt"></a></span>
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Discussion on fix can be found on kowari-developer archives at
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="nt"><a</span> <span class="na">href=</span><span class="s">"http://sourceforge.net/mailarchive/message.php?msg_name=1DD30215-4208-4637-A597-760C196F2666%40nova.org"</span><span class="nt">></span>http://sourceforge.net/mailarchive/message.php?msg_name=1DD30215-4208-4637-A597-760C196F2666%40nova.org<span class="nt"></a></span>
</code></pre> Mulgara - Feature #57 (New): Extend use of Annotations to improve transparency of deferral based ...https://code.mulgara.org/issues/572007-04-17T05:51:27ZAndrae Muys -andrae@netymon.com
<pre>
<code class="html syntaxhl">[[ReresolvableResolution]] needs to be removed and replaced with an Annotation.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
All Major Tuples that provide operations on Tuples need to be modified to provide aggregated access to their operands annotations when their operands provide them.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
As a longer term goal we should rephrase the annotations in terms of complexity estimates for reordering/sorting/etc operations as well as constraints on join ordering to permit more nuanced optimisation of joins - this however needs to wait until we are fully exploiting the capabilities of the existing annotations.
</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 - Feature #21 (New): HybridTuples should defer sort and support prefix-define/reresolvehttps://code.mulgara.org/issues/212006-09-26T03:51:34ZAndrae Muys -andrae@netymon.com
<pre>
<code class="html syntaxhl">Currently [[HybridTuples]] performs it's sort when it is constructed. This forces the evaluation of its argument before join-optimisation has an opportunity to specify a desired prefix or reresolve. [[HybridTuples]] should defer it's sort until at least the first call to beforeFirst.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Considerations:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Reresolve - If [[HybridTuples]] argument is Reresolvable [[HybridTuples]] should support passing this argument through.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
[[DefinablePrefix]] - If our argument is unordered then a projection is free, so we should expose this to the join optimisation. However note that if we are only sorting once, then we cannot pass this call through to the argument. Rather we should project the argument to maximise the prefix length available.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Single vs. Multiple sorts - A sort is O(nlogn), and a n from m prefix is O((0 from m)^((n - m) / m)). If we can increase the prefix length sufficiently to pay for the cost of the extra sorts we should resort on each call to beforeFirst(). Note that if the argument is itself prefix-definable then the cost of a sort is in terms of the estimated reduced length.
</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 - Feature #18 (New): Provide a language independent interface to Mulgara compatible with ...https://code.mulgara.org/issues/182006-09-14T04:38:41ZAndrae Muys -andrae@netymon.com
<pre>
<code class="html syntaxhl">We need to support access to the entire Session API from languages other than java.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Both xml-rpc and REST have been proposed as alternatives. OTOH we should probably support both.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
XMLRPC because of it's wide language support and classic-rpc model.
<span class="nt"><br/></span>
REST because it is a better fit to W3C architecture, and provides benefits when working with loosely coupled distribution.
</code></pre> Mulgara - Feature #17 (Closed): Rewrite WebUI to remove Barracuda and simplify.https://code.mulgara.org/issues/172006-09-14T04:31:46ZAndrae Muys -andrae@netymon.com
<pre>
<code class="html syntaxhl">From Paul's email to Mulgara-dev 2006-09-12:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
The [[WebUI]] has several problems associated with it, not least the fact that it violates some of the client/server rules inside the server, requiring a few hacks to make it work right. Since it was only ever a demo, I would have liked to be rid of it, but enough people have told me they rely on it to convince me that we need to keep it. :-(
<span class="nt"><br/></span>
<span class="nt"><br/></span>
If we ARE to keep the [[WebUI]], then I think we need to re-write it completely. It is currently using Barracuda, which is too heavyweight for what it's doing. I believe that no one here is all that familiar with Barracuda anyway (it was implemented by Ben, who of course isn't working on Mulgara anymore). Given how simple the page is, we can probably hand code it together without a great deal of effort (or use a simpler tool), and remove the dependency on xmlc-all-runtime-2.2.jar
<span class="nt"><br/></span>
</code></pre> Mulgara - Feature #16 (In Progress): Add Rules for OWL DL/Full supporthttps://code.mulgara.org/issues/162006-09-14T04:28:54ZAndrae Muys -andrae@netymon.com
<pre>
<code class="html syntaxhl">Extend the new Rules Engine to support OWL Full.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Provide rule sets for OWL DL and OWL Full.
</code></pre>