Tag Archives: CDI

CDI & EJB: Sending asynchronous mail on transaction success


Hello again! 🙂 This time I’ve chosen a common task that most of the time, in my opinion, is done the wrong way: sending e-mails. Not that people can’t figure out how e-mail APIs work, such as JavaMail or Apache’s commons-email. What I usually see as a problem is that they underestimate the need to […]

https://rodrigouchoa.wordpress.com/2014/10/22/cdi-ejb-sending-asynchronous-mail-on-transaction-success/

Transaction handling in EJBs and JavaEE7 @Transactional


Handling transactions in EJBs is easy, right? Well, in theory it should be. But how does the theory translate into reality once you leave the ivory tower? I’ll show you a small example. Let’s assume we have 2 infrastructure service EJBs: @Stateless public class StorageServiceImpl implements StorageService { private @EJB CustomerService customerService; private @PersistenceContext EntityManager […]

https://struberg.wordpress.com/2015/04/21/transaction-and-exception-handling-in-ejbs-and-javaee7-transactional/

Injecting Kubernetes Services in CDI managed beans using Fabric8


via iocanel.blogspot.in

The thing I love the most in Kubernetes is the way services are discovered. Why?

Mostly because the user code doesn’t have to deal with registering, looking up services and also because there are no networking surprises (if you’ve ever tried a registry based approach, you’ll know what I am talking about).

This post is going to cover how you can use Fabric8 in order to inject Kubernetes services in Java using CDI.

Using JCache with CDI


via Using JCache with CDI | Voxxed.

The JCache JSR (JSR-107), finalized in late 2014, provides a standard mechanism to cache values in a map-like structure using a key. There are a number of different JCache implementations to choose from, and swapping between them should be no more difficult than swapping out .jar files on the classpath. In these examples I will use Hazelcast – it provides a distributed cache, giving the benefit that all of the nodes in the cluster are using the same cache and working consistently.

Migrating a JSF Application from Spring to Java EE 7/CDI


via Migrating a JSF Application from Spring to Java EE 7/CDI (The Aquarium).

One of the most important things to do at this stage of the life-cycle of Java EE is highlight successful adoption stories. We have been doing just that for a long time through our adoption stories blog as well as JavaOne. JavaOne 2014 was particularly good in this regard and JavaOne 2015 looks to be even better. Indeed we hope the folks with great adoption stories that submitted last year but did not get accepted will resubmit next year. We will continue to highlight some of those sessions from JavaOne 2014 in the next few months. In this vein I’d like to highlight a very interesting real world story of migrating a JSF based web application from Spring to Java EE 7 and CDI shared by Mario-Leander Reimer of QAware.

CDI & EJB: Sending asynchronous mail on transaction success


via CDI & EJB: Sending asynchronous mail on transaction success | Code to live. Live to code..

This time I’ve chosen a common task that most of the time, in my opinion, is done the wrong way: sending e-mails. Not that people can’t figure out how e-mail APIs work, such as JavaMail or Apache’s commons-email. What I usually see as a problem is that they underestimate the need to make the sending mail routine asynchronous, and that it also should only run when the underlying transaction commits successfully (most of the time).

Think of the common use case where a user is shopping online. When he’s done, he will probably want to receive an order confirmation e-mail. The process of making an order is kinda complex: We would usually insert records in a lot of different tables, also possibly delete records to remove items from stock and so forth. All of this, of course, has to be accomplished in a single atomic transaction:

Unsynchronized Persistence Contexts in JPA 2.1/Java EE 7


via Unsynchronized Persistence Contexts in JPA 2.1/Java EE 7 (The Aquarium).

One of the more obscure features introduced in JPA 2.1 and Java EE 7 is the unsynchronized persistence context. It’s not too surprising that the community does not seem to discuss it much – it’s really geared towards somewhat an edge case.

Prior to JPA 2.1, the entity manager is always synchronized with the database when a JTA transaction commits. This poses a challenge if you have a multi-step workflow (let’s say in a stateful session bean/CDI conversation/JSF flow) where you want some data to be flushed to the database on transaction commit at a given stage of the workflow but not all – but you do eventually want to synchronize all changes at some other point in the workflow. Non-standard solutions like Seam and the Hibernate flush mode have been the answer in the past to get around this problem. This is now solved in JPA 2.1 via the unsynchronized persistence context. In an unsynchronized persistence context changes are not automatically flushed to the database on transaction commit. Rather, you explicitly join the transaction when you want changes synchronized.

Hantsy Bai does a decent job explaining this through code examples. By far the best explanation of the feature comes from specification lead Linda DeMichiel. Check out minute 11-14 in the short video below (if you are having trouble accessing the embedded video it is available here).