Thanks Rob and Andy.
then as MutiUnion is a view, do I need a transaction to create it?
On 2017-09-14 11:21, Andy Seaborne wrote:
>
>
> On 14/09/17 09:54, George News wrote:
>> Hi,
>>
>> Continuing with my issues with transactions, next question ;)
>
> question*s* :-)
>
>>
>> 1) If I get a model as a result of a multiunion or a set of entities
>> from a read transaction, will I be able to use this model after the
>> transaction ends (i.e. in a SPARQL request).
>>
>> MultiUnion union = new MultiUnion()
>> dataset.begin(ReadWrite.READ);
>> union.addGraph(dataset.getNamedModel("A").getGraph();
>> union.addGraph(dataset.getNamedModel("B").getGraph();
>>
>> Model m = ModelFactory.createModelForGraph(union);
>> dataset.end();
>>
>> // Execute SELECT SPARQL over m without opening a read transaction
>>
>> Will it work? What data is included?
>
>
>> Will it work?
> No.
>
> MultiUnion is a view - it does not actually have the triples, only
> pointers to the graphs, and the graphs are views of the dataset, which
> is where the data really is.
>
>> 2) Suppose I have a webservice exporting read/write functionality from a
>> TDB. Every request opens a transaction over the TDB. If the request is
>> taking too long the HTTP client closes the connection. What happens with
>> the transactions? From my understanding, once the connection from the
>> client is closed, all resources for the call are freed at the server and
>> then the transactions will be somehow aborted and released. Am I right?
>
> If the client closes the connection, the server does not know until it
> tries to use the connection. If written correctly, the server needs to
> clear up when it can.
>
> https://stackoverflow.com/questions/2962196/detecting-client-disconnect-in-tomcat-servlet
>
>
> Txn does the clearup:
> https://jena.apache.org/documentation/txn/txn.html
>
> or long way:
>
> dataset.begin(WRITE)
> boolean commitDone = false;
> try {
> ... action ...
> ... some IOException on the response connection ...
> dataset.commit()
> commitDone = true;
> } finally {
> if ( ! commitDone )
> dataset.abort();
> dataset.end();
> }
>
> though
>
> dataset.begin(WRITE)
> try {
> ... action ...
> dataset.commit()
> } finally {
> dataset.end();
> }
>
> works just fine - end() forces an abort if no commit or abort was called.
>
> ARQ has query timeouts.
>
>> Thanks a lot for you invaluable help. I feel really sorry for bothering
>> so much, but I'm suffering from some stability issues on the developed
>> system (mainly memory leaks, etc.) and need to properly understand if
>> I'm making things the right way.
>>
>> Regards,
>>
>
> Andy
>
