This is fantastically on-point and helpful. I'll whip this up and try it (and hope that result will be *****EXPECTED). Thanks a million.
On Wed, Mar 21, 2012 at 10:08 AM, Andy Seaborne <[email protected]> wrote: > 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 >
