cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <>
Subject Cayenne transactions edge cases
Date Tue, 06 Sep 2016 10:06:42 GMT
Transaction handling is "fun". I am really glad our users don't have to deal with transactions
directly 99.9% of the time. There are a number of edge cases where Cayenne can't make it fully
transparent though. The most typical one is when multiple DB operations overlap. E.g.:

1. Operations within callbacks and listeners.
2. Operations within an iterated result scope with a single DataSource.
3. Operations within an iterated result scope with multiple DataSources (a typical use case
with LinkMove).

Our single thread-bound transaction mechanism often falls short in these cases, as it has
to pick a single default behavior out of many possible options. Just yesterday I had to deal
with #3 scenario (in LinkMove transactions for source and target DataSources were stepping
on each other .. you've probably seen the Jiras). I had to unbind the transaction of the iterated
result object from the thread, so that ops executed within the iterator would not try to attach
to it. This solved conflicts arising in #3 scenario (transactions against 2 DataSources were
stepping on each other), and hopefully this is a good default.

Still I feel we'll need more flexibility in a general case. Overlapping operations means your
code (not just Cayenne code) is executed inside a transaction and you suddenly start to care
about isolation levels, commit/rollback scope and other fun staff. I am not suggesting any
solutions yet. Just thought that I should mention the problem. Hopefully even in these advanced
cases we can stay true to Cayenne "you don't have to care about transactions because we do
it for you" motto :)

View raw message