Skip to content

Transaction – JTA/JTS

July 15, 2011

Tx.being/commit/rollback(programmatic)
Programmatic tx model should only be used: client initiated tx, localized JTA Tx, and long running Tx.
Client initiated Tx – then calls declarative Tx running in server/ejb. Also Exceptions should be carefully managed in programmatic tx + know that there is a problem of Tx context where in the stateless session bean the tx started in one SSB cannot be passed on to the Tx started in another thread of another SSB.

JTS = database driver
JTA = jdbc connector

To decide between “Required” and “Mandatory” – you need to see that if a method is not rolling back the transaction – then the method should be marked mandatory.

Transaction Isolation Level : Setting is DEPENDENT on the DB and the APPSERVER features.
But TxIsolation if high is low on concurrency and high on consistency. if low is high on concurrency and low on consistency.

Repeatable Read: These locks ensure that the rows touched by the query cannot be updated or deleted by a concurrent session until the current transaction completes (whether it is committed or rolled back). These locks do not protect rows that have not yet been scanned from updates or deletes and do not prevent the insertion of new rows amid the rows that are already locked.

Specifies that statements cannot read data that has been modified but not yet committed by other transactions and that no other transactions can modify data that has been read by the current transaction until the current transaction completes

Shared locks are placed on all data read by each statement in the transaction and are held until the transaction completes. This prevents other transactions from modifying any rows that have been read by the current transaction. Other transactions can insert new rows that match the search conditions of statements issued by the current transaction. If the current transaction then retries the statement it will retrieve the new rows, which results in phantom reads. Because shared locks are held to the end of a transaction

SERIALIZABLE
Specifies the following:
-Statements cannot read data that has been modified but not yet committed by other transactions.
-No other transactions can modify data that has been read by the current transaction until the current transaction completes.
-Other transactions cannot insert new rows with key values that would fall in the range of keys read by any statements in the current transaction until the current transaction completes.

3 DESIGN PATTERN for Transactions:
=============================================

1/ client managed tx model : client manages tx start and end and server domain service must not rollback tx and most importantly mark it as Mandatory. the tx is propagated through the RMI using programmatic[ejb]/declerative[spring] at Client and declarative at the server side.

2/ Domain Service Owner Transaction Model – places the responsibility of managing of Tx start/end type on the service layer. / declarative tx/
DAO – no tx responsibility. Client – no Tx respon

3/Server Delegate Owner Tx Design Pattern:
Instead of client making 40 independent calls to the server – or the domain services each managing the tx of 40 calls – setup all calls in the Command Object – that is processed by a bean (component) – so there is one component processor that manages all transactions – and all other domain services in the app are just simply used in the tx.
Command object is passed by the client to the server and the server has a bean that acts like a command tx method call processor.

Advertisements
No comments yet

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: