You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is currently no RollBack public function as part of the transactionCommitter
Updated by Brett Powell about 2 years ago
When doing a number generator for Talbot we ran into the following issue.
A DBNumberGenerator was being used.
This had code to increment the number (as part of the transaction committer
Then a whole bunch of stuff that all got added to the transaction committer
then the commit.
The DB number generator now has the capability to rollback correctly but
if the error occurs any time other than the commit then no rollback happens.
It would seem that an error handler around all the code with a
Transaction committer.Rollback would make sense.
This is however ranging dangerously close to the long running transaction pattern that we have previously discussed.
Updated by Mark Whitfeld about 2 years ago
Hi Brett.
Do you mean the 'Unit of Work' stuff we spoke about when you refer to the long running transaction pattern?
I have needed this as well and thought about having it in the transaction committer, but it just doesn't feel right there.
The changes are made outside of the transaction committer, so why would the transaction committer be concerned with rolling these back?
I think that this would be something that should rather fit into a 'Unit of Work' type pattern: http://www.habanerowiki.com/index.php?title=Future_Features#Unit_of_work_.28Fowler_Enterprise_applications.29
Gee, if we could get that implemented, that would be epic!
The text was updated successfully, but these errors were encountered:
Redmine Bug #2088
There is currently no RollBack public function as part of the transactionCommitter
Updated by Brett Powell about 2 years ago
When doing a number generator for Talbot we ran into the following issue.
A DBNumberGenerator was being used.
This had code to increment the number (as part of the transaction committer
Then a whole bunch of stuff that all got added to the transaction committer
then the commit.
The DB number generator now has the capability to rollback correctly but
if the error occurs any time other than the commit then no rollback happens.
It would seem that an error handler around all the code with a
Transaction committer.Rollback would make sense.
This is however ranging dangerously close to the long running transaction pattern that we have previously discussed.
Updated by Mark Whitfeld about 2 years ago
Hi Brett.
Do you mean the 'Unit of Work' stuff we spoke about when you refer to the long running transaction pattern?
I have needed this as well and thought about having it in the transaction committer, but it just doesn't feel right there.
The changes are made outside of the transaction committer, so why would the transaction committer be concerned with rolling these back?
I think that this would be something that should rather fit into a 'Unit of Work' type pattern:
http://www.habanerowiki.com/index.php?title=Future_Features#Unit_of_work_.28Fowler_Enterprise_applications.29
Gee, if we could get that implemented, that would be epic!
The text was updated successfully, but these errors were encountered: