On 21/03/12 13:03, Bernie Greenberg wrote:
Hi; I'm new to Jena, and maintaining an extant piece of (multithreaded
Java) Jena-wrapper which latter reflects only a partial understand of some
things on which I (or several of us here) could use some clarification.
"Models". When you ask a dataset "getDefaultModel", do you get a fresh,
private data structure, whose read-write consistency is your own problem,
like (I assume) the produce of "ModelFactory"'s, or do you get a pointer
to something which is "part of" the dataset, and (modulo the need to
transact and commit) might well change between one visit and the next, by
activity of other threads?
The latter - it's a view of the dataset.
I understand that "commit"ing the model commits the changes to the
dataset. I am trying to use the new "begin" and "end" synchronization
primitives, and I do not understand the relation between the seemingly
parallel sets of primitives on the model and the dataset (including
"commit"), in specific, the relation between model.commit() and
dataset.commit() on the dataset from which the model has been
getDefaultModel'ed. I changed our code to abandon model.commit() for
dataset.commit(), but I'm not understanding why it seems to work without
knowing the answers to the questions above.
It is essential to use the dataset transaction mechanism not the model one.
Model.supportsTransactions() is false for a model backed by TDB because
the model does not support transactions properly.
(it maybe possible to wire this up at some later date but Model
transaction interface does not indicate read vs write transactions which
is required by TDB currently. It would be possible to provide
promotable read->write transactions subject to some interesting (=
"scary") stuff about deadlock by congestion or internal locking -- but
it's not done).
What's more, Jena outputs, in red, no less, "*********** UNEXPECTED [1]"
with seeming regularity (yesterday I found it in the Jena source, but can't
seem to today) in this arrangement, but in any case, it is not a positive
sign that I have this right. The diagnostic ..."could be clearer"...
It should not happen! It's an internal consistency check. The code
notes it, and keeps going.
(it's in TDB in NodeTableTrans)
Right now, we procure one Model from the dataset at startup, and repeatedly
modify and commit it (under its own "begin(WRITE)/end"), while the reader
thread does begin(READ)/end). Jena's posted code examples, though, ask
getDefaultModel() within the transaction brackets (begin/commit/end).
What's right here?
The latter - get the model after the transaction has begun, don't reuse
it after the transaction ends. It's stateless and should not be very
expensive to create.
Because of modes of behavior to give backwards compatibility, getting
models from the base dataset (before any transaction) will work but
can't be transactional and can't be used safely after the first
transaction has started.
I am led to believe that asking this list is the shortest path to getting
it right...
Thanks
Bernard Greenberg
Basis Technology
Cambridge, MA, USA
Andy
