In Java EE applications you are safe to consider that every method in a session bean has an associated transaction, since there is an implicit declaration of the transaction attribute required. If you like to change this behavior you have to configure this proactively by adding the annotation @TransactionAttribute with another value (see enum TransactionAttributeType). Context and Dependency Injection (CDI) does not have such an implicit declaration and no direct container managed support for transactions. But it has a very nice realization of the interceptor concept. This post shows, how to facilitate an interceptor in order to add a transaction to every (or a selection) method in a CDI bean, if it does not already exist. This is the default behavior of required.
(more…)
CDI and Transactions e.g. in JBoss-7.0.2
January 16, 2012 — jonnyCircumvent Nested Transaction Issues in Tapestry-5.x
January 12, 2012 — jonnyAjax component events may be wrapped in a transaction as I pointed out in “Transaction Handling for Ajax Components in Tapestry-5.x“. But on some occasions an Ajax component event is surrounded by a component event. So the code in the ControllerUtil of article “Transaction Handling in Tapestry5” will lead to ‘transaction already active’ problems, since we try to begin a transaction in the nested ajax component event although there is already an active transaction attached to the current thread. We can overcome this situation by checking, whether an active transaction is present and begin/commit/rollback a new transaction iff not. This behavior is similar to the default transaction attribute REQUIRED in Java EE.
(more…)
Transaction Handling for Ajax Components in Tapestry-5.x
January 12, 2012 — jonnyIn “Transaction Handling in Tapestry5” I described, how to configure transactions wrapping a complete page or component render request. The same is necessary (possible) for Ajax components. Besides having less transactions and sharing the first-level-cache for subsequent calls, this realizes the “Open Session in View Pattern” automatically. So you can access the database lazily via getter from an entity, for example, without running into lazy loading exceptions due to the fact that the transaction has been closed and the entities are detached already.
(more…)
Transaction Propagation for Remote calls
February 5, 2010 — jonnyI didn’t find a clear statement whether transactions are propagated for remote calls in Java EE 5. So I tested it by creating two enterprise applications being deployed in different ears to the same JBoss-5.1.0-GA. In short: YES, the transaction is propagated and a rollback on a calling method initiates a rollback on the remote transaction, too. The willing reader might read on in order to get to know the test setup. (more…)
