Geek Answers Handbook

Object level transaction management model

I am trying to find a better way to handle transactions at the object level (and not at the database level). A brief example: 4 objects A, B, C, and D. A starts a transaction and calls methods in B and C. At the same time, transaction C also calls D. Called methods should not always participate in this transaction, but they can be called themselves by oneself. Are there any templates for object level transaction management?

I really did not find anything, so I came to the following: use TransactionContext where you can register TransactionListeners. If a transaction is launched using TransactionContext, it will enter the launched transaction into each registered listener, which, in turn, will use the launched transaction or, accordingly, start it on its own, if necessary. That way, I can freely decide if I want the object to participate in my transaction or not.

The problem occurs when there is a chain of object calls, as described above. When starting a transaction, I just know that B and C must be involved in the transaction, so I add them to the TransactionContext. But what about D? I really don't want to pass the TransactionContext to B and C.

I would appreciate some input to my approach, as well as some pointers to tested samples (even better).

+5
source share
4 answers

"I really don't want to pass the TransactionContext to B and C."

Why not? They participate and they delegate to other objects.

Or

  • Everyone must register. This means that you must delegate registration. Aknows that he disconnects before Band C. Each of which may (or may not) have additional delegates for registration. This is relatively simple to implement using the RegisterYourselfAndYourDelegatees method.

  • . . . , Context - , .

    . Java , .

    Python ; .

+2

Spring framework ( Java, .Net-) . :

  • ( , );
  • ( );
  • .

. , .

Spring .

+1

: Prevayler

Prevayler is an object persistence library for Java. It is an implementation of the
System Prevalence architectural style, in which data is kept hot in Memory with
changes journaled for system recovery.

Prevayler ' s architecture is illustrated in the diagram shown there. Prevayler [1]
serves as a transactional barrier for the business objects [2] of your application,
held in Memory. You encapsulate all modifications of your business objects into
instances of the Transaction interface [3], much like a " command " pattern
(though different from a command in some details of the pattern). Whenever 
you ask Prevayler to execute a transaction on your business objects [4], Prevayler
first writes the transaction object to a journal [5] so that data is not lost if your
system crashes. Prevayler can also write a snapshot of your entire business object
graph [6] as often as you wish. Prevayler uses the latest snapshot together with
the journals to automatically recover your business objects from disk [7] on
application startup by restoring the snapshot and then re-executing every
transaction that was originally executed after that snapshot was taken.

, .

0

, ScopeGuard patten. , , .

, ScopeGuard, ( ) , A, B, C, D .

0

More articles:


All Articles