On 24/07/14 13:44, Claude Warren wrote:
The detached result set takes more memory, no? So for large results on a
heavily loaded system this is an issue. In addition creating a detached
set takes time, so in systems where response times are critical it may
makes sense to return the streaming result set.
For robust production systems, detaching the result set can be wise
anyway because of slow clients.
In JDBC, normally the results are fully returned before the app client
gets a chance to run - I think this is to make the JDBC driver
defensive. Only some systems offer option true streaming and then with
additional system-specific constraints.
It does not have to be in memory - part of what I'm doing with
rdf-thrift is efficient I/O for result sets so, if necessary, results
can be paged to disk for isolation.
Andy
On Thu, Jul 24, 2014 at 12:40 PM, Andy Seaborne <a...@apache.org> wrote:
I won't override begin/commit/end to do this.
FWIW I think the idea that "commit()" does not actually cause a persistent
change on disk is bad. The contract on commit() is ACID, specifically D
so ".commit() ; System.exit(0) - restart" smeans teh app is guarantteed to
see the change.
This is just reference counting?
What happens if the nesting never un-nests?
Better is to separate concepts and have a counter - that is a samll
mamangement library for trasnactions:
TransactionLevelMgt mgr = new TransactionLevelMgt(dataset) ;
mgr.beginLevel(dataset, WRITE) ;
mgr.endLevel() ;
mgr.abort() ;
and endLevel does a "commit()" when the level count returns to zero.
Assume a QueryResult object that comprises the result set from
a query and the dataset it was run against.
Surely the right way is to create a detached result set? (no tied to the
transaction or the query execution)
Andy
On 24/07/14 10:32, Claude Warren wrote:
As you can probably guess from my recent posts here, I am working with
transactions, datasets, and web applications.
In Spring there is this concept of "joining a transaction". Basically it
works like this:
When calling begin()
If a transaction is in progress and is the proper type (Write request must
be write, Read request may be Read or Write) use it.
if a transaction is in progress and is not the proper type (write request
with read transaction in progress) throw an exception
if no transaction is in progress start one of the proper type.
when calling commit()
if we joined the transaction do nothing.
if we started the transaction commit it.
when calling abort()/rollback()
if we joined the transaction throw an exception
if we created the transaction abort rollback the transaction.
In our special case of end() I think we would do something like commit().
I have a class that handles this by wrapping the real dataset and
providing
this functionality via thread local variables.
usage case is something like:
In a web service we have a query and a dataset to query against. We want
to stream the results to the client without creating the potentially large
file locally.
Assume a QueryResult object that comprises the result set from a query and
the dataset it was run against.
1. service call comes in to a JAX-RS annotated service
2. service starts a READ transaction.
3. execute the query
4. returns a QueryResult (see above)
5. system uses a @Provider annotated class to format the result as per
the request.
6. the transaction.end() is called.
As you can see the transaction is started in one object and is logically
not complete until the end of an second object.
If anyone is interested I'll put the class in the jena-commons.
