Transactions inside transactions without merging them?

[Gösta]

Hi Warp guys!

Thanks for a great library!

We have a Quartz job that manipulates a big number of entities.
We would like to isolate every entity manipulation into its own
database transaction ending with a commit.
But we also want the job to be able to save manipulations done
elsewhere by using a "global" job transaction.

The problem is that each entity manipulation transaction gets merged
with the global job transaction.
This means that only one commit will be made; when the job is
finished.
Instead we want to have commits after each entity manipulation and one
when the job is finished.

So can the below code's process transactions be stand-alone and
committed immediately while inside the job transaction?

We understand that it can be solved by moving the @Transactional on
the job method to the storeJobStatistics method in this simple case.
But we are looking for the extra security that everything gets
committed by using a global transaction instead of having to specify
@Transactional for a number of methods in the job.

@Transactional
job() {

for(all entities) {
process(entity);
}
storeJobStatistics();
}

@Transactional
process(entity) {
// entity gets processed
}

storeJobStatistics() {
// store job statistics
}

Thankful for help.

Best regards,
Gösta

[Dan Retzlaff]

JPA and Hibernate do not support nested transactions, and neither does Warp persist. JDBC only kind of supports "nested transactions" through save points, but to use those you'll have to give up your ORM framework. You might consider an alternate design such as use of a staging tables/database for your inner-transaction work, then moving that over to live tables/database in a later transaction.

Please correct me if I'm wrong, but I've run into this a few times and the preceding advice was always my takeaway.

Regards,

Dan

--
You received this message because you are subscribed to the Google Groups "warp-core" group.
To post to this group, send email to warp...@googlegroups.com.
To unsubscribe from this group, send email to warp-core+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/warp-core?hl=en.

[Dhanji R. Prasanna]

Sounds about right to me. =)

Dhanji.

[Gösta Jonasson]

Thanks for your answers.

My reasoning might be flawed but is there no solution like for example
a @Committed annotation?
That annotation wouldn't start a transaction before the method but
would make sure all uncommitted entities are committed after the
method.
(That behavior can today be simulated by calling an empty
@Transactional method lastly in the method but that doesn't feel
right.)

In that case the code would be:

@Committed
job() {

for(all entities) {
process(entity);
}

storeJobStatistics();
}

@Transactional
process(entity) {
// entity gets processed
}

storeJobStatistics() {
// store job statistics
}

Regards,
Gösta

[Dan Retzlaff]

Any save or update operations you execute should be done within a
transaction. If that's not what you're doing, you're getting away with
some inadvisable funkiness. If you're just suggesting that you compile
statistics in-memory using read-only transactions, then create/save
the results in a separate read-write transaction, then sure, that
works. You won't have any ACID guarantees across those transactions
(consistency in particular), but maybe that's okay for your
application.

2010/11/8 Gösta Jonasson <gos...@gmail.com>: