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.
