[Mulgara-general] Two Database instances in the same process?

Paul Gearon gearon at ieee.org
Sun Sep 27 20:56:04 UTC 2009


Hi Karsten,

On Sun, Sep 27, 2009 at 4:06 PM, Karsten Huneycutt <kph at skuld.us> wrote:
> Hello --
>
> First:  Does Mulgara 2.1.3 allow one to have two distinct Database
> instances (and therefore two distinct XA1.1 StringPools, etc) in the
> same process?

I wish.  :-(

Unfortunately, no. It's mostly there, but there are a few static
variables that remain. I always wanted to fix this, but I've never
tried to track it all down, because until now no one ever asked for
it.

> If it doesn't, then I'll stop trying to do that.   If it does, then I
> must be doing something incorrectly...

Nope. The odds are that you're doing it right.

The only way to make it work right now is to use two separate
processes and communicate via HTTP or RMI.

> A bit of background as to why I'm trying to do this:  I need to have
> something that applies rules to a set of graphs (that the consuming
> application accesses via a view) in the background that doesn't stop
> modification of the original graphs while the rules are being
> applied.  Each modification of the original graphs triggers a
> background reasoning run, so any entailments that are invalidated by
> the modifications will be corrected on the next pass of the reasoner;
> for me, this temporary inaccuracy is an acceptable trade-off for the
> responsiveness of modification that I require.

You know you can always just have the results of rules sent to a
separate graph. That would leave the first graph alone. Then when you
want to look at the final results you select from a union of the
original and the results graphs.

> I first tried to copy the sub-graphs over which I wanted to reason
> into a separate graph in the same database, do the reasoning into a
> separate entailments graph, and then copy the results back into an
> entailments graph in the view.  That didn't work, of course -- as I
> learned, the "apply" command write-locks the entire database, not just
> the graphs on which it's applying, which holds up modification of the
> original graphs for the three to five minutes while the entailments
> are being calculated.

Yes, we only allow for a single writer at a time. It's to do with the
architecture of the phase trees we use. We're working on changing
this, but with limited resources it's slow going.

> So, I went down the road of copying the graphs to a separate database
> in the same process.

That would work... but for now you need separate processes.

> The following example code shows what I'm trying to do:

<snip/>

> Note in particular that it says "/tmp/path1/...", which was correct
> for db1 but not for db2!  What am I doing incorrectly?
>
> I'm currently shipping the reasoning off to a separate Mulgara
> process, using temporary files and RMI, but that seems inefficient,
> and I'd like to keep it all in the same process.

It's not THAT bad, but I see your point.

> Alternately, is there a better way to do what I described than using a
> separate database (be it in the same process or a separate process)?
> (Note that, for now, I don't care so much about memory use or disk use.)

Not that I can think of. At least, not yet.

> My apologies if these questions have already been asked and answered;
> I couldn't find the answer in the archives of the lists or in the wiki.

No, but they are probably good things to put in there. I need to
devote a little time to documentation, and that seems as good a place
to start as any.

Paul



More information about the Mulgara-general mailing list