Two corrections to what I just posted (corrected in quotation):
1)
Obviously, I meant "dsw = new Wrapper()", not "Wrapper = " and in the
comment.
2)
Add "model", "default-model" (I had already said graph) to the objects
to be diagrammed.
On Fri, Mar 30, 2012 at 7:53 AM, Bernie Greenberg <b...@basistech.com> wrote:
> Morning has broken on the American East Coast, but apparently not my app,
> yet!
>
> This new documentation is much better. Largely on its account, I'm going
> to demur posting an operative example, but I will write about what I did
> that should be noted by multiple readers of this thread.
>
> I discard a dataset (close it, and obtain a new one in that thread if/when
> needed) after it has been commit()/end()'ed for a WRITE operation. If this
> isn't necessary, let me know (previous email suggested that it was), but if
> it really is, that fact should be added to the documentation section you
> just improved, as well.
>
> Also, in my own practice, I use try {} finally {} to close datasets I have
> created. Perhaps this is no longer important (because of transaction
> ACIDity); if that be so, please say so (perhaps Java garbage collection and
> active destroy-handlers now suffice), or else, your examples should close
> datasets properly. You should say what, if anything, happens to you if you
> fail to "close" a dataset all of whose WRITE transactions have been
> successfully committed.
>
> I do my work by means of a "Wrapper"/proxy object around "dataset". The
> "Wrapper" contains a "dataset" variable, initially null. There are two
> operations on the Wrapper:
>
> 1. Dataset *getMaybeCreateDataset*(){ if (dataset != null) return
> data; else {dataset =
> TDBFactory.createDataset(staticStringContainingLocation); return dataset;}}
> 2. void *shutdown *() {if (dataset!= null) dataset.close();
> dataset=null;}
>
> The important thing is that I create one of these wrappers per thread, or
> more precisely, in my server environment where request handlers are invoked
> from a thread pool, I code
>
> Wrapper dsw = null;
> try {
> dsw = new Wrapper();
> .... all that was there ... now using dsw...
> } finally {dsw.shutdown();}
>
> in each handler that expects to interact with Jena. I pass this object
> around the call stack; it is not static (although I suppose the pointer
> could be ThreadLocal, Occam's razor cuts against it). When I need a dataset
> for a transaction, I call my Wrapper's getMaybeCreateDataset. If the
> transaction was a WRITE transaction, I call its shutdown() after I call
> end() on what I obtained.
>
> Bernie
> p.s., add "models" to the list of object-types to participate in the new
> diagram set.
>
>
>
> On Fri, Mar 30, 2012 at 5:22 AM, Andy Seaborne <a...@apache.org> wrote:
>
>> On 29/03/12 19:51, Bernie Greenberg wrote:
>>
>>> I have seemingly gotten this to work (but I said that last time, too) and
>>> endure our fullest battery of tests, under the assumption of per-thread
>>> "dataset"s, discarding them after a commit/end and creating a new one for
>>> the thread when needed.
>>>
>>> What the documentation needs, besides clear design guidelines for and a
>>> minimal code example of multithreaded, transactional use, is a family of
>>> diagrams explaining the scope, extent, uniqueness, and ownership of all
>>> the
>>> kinds of data objects you can get (e.g., maps, datasets ...) with respect
>>> to each other, databases, and threads.
>>>
>>> Thanks again ----
>>> Bernie
>>>
>>
>> Hi Bernie,
>>
>> There's a partial, quick change to the documention so it's at least been
>> vaguely helpful,
>>
>> http://incubator.apache.org/**jena/documentation/tdb/tdb_**
>> transactions.html#multi-**threaded-use<http://incubator.apache.org/jena/documentation/tdb/tdb_transactions.html#multi-threaded-use>
>>
>> Andy
>>
>
>
