Blog « Piotr Nowicki's Homepage

Few days ago, during our regular code review, one of my colleagues raised a question what would happen — and if it’s even possible — when a CDI Observer (so a method with parameter annotated @Observes) would be invoked multiple times at the same time for different event instances. In other words, after producing few events, is it possible that the following method will be processed by more than one thread at the same time:

public void observe(@Observes MyEvent myEvent) { ... }

After thinking about it I’ve decided to run a few tests and describe results in this post.

First results: it occurred that CDI Events are fired in synchronous mode which was a bit surprise for me. Why?

Up to this time, I’ve seen it this way: CDI observers allows me to very cleanly separate event producer from event consumer, so I don’t have any hard-coded registering of listeners, maintaining a list of listeners and manually informing them. The CDI container does everything for me.

Therefore, if we have cleanly separated producers from consumers I thought that there exists some kind of event bus running in specialized, thread executors pool which is responsible for mediation between registered events and invoked observers methods. I guess I based this assumption on other event/listeners solutions like Google Guava EventBus. They give you a chance to define if you want to use synchronous (default, EventBus) or asynchronous event dispatchers (AsyncEventBus.)

Moreover, if EJBs are both: producer and consumer, I assume it would have the same features as asynchronous EJB calls when it comes to transactions. The only possible JTA transaction attribute for asynchronous event observer would be: REQUIRED, REQUIRES_NEW or NOT_SUPPORTED.

Now that’s all how I expected it to work which seems to be quite different from the current status. The real life shows that CDI events are synchronous.

There is an issue for making asynchronous events available in CDI 1.1 but I’m not sure what is the current status of this feature and didn’t find a word about it in CDI 1.1 (part of Java EE 7).

Let’s see how we can deal with it on our own.

Continue reading →

Java EE 7 has been recently accepted by the Executive Committee. This means that soon we should have Java EE 7 application servers available on the market. One of the specifications that constitutes Java EE 7 is JMS 2.0. Some interesting improvements were introduced since version 1.1.

JMS has a lot of weird stuff like: Connection#createSession(boolean transacted, int acknowledgeMode) method.

First method argument (transacted) defines if the session should be transacted. Java EE applications have JTA that takes care of transactions. We can choose if transactions are supported (default) or not. So why do we need this argument then?

Second method argument (acknowledgeMode) is an integer constant taken from Session object. Seriously, integers constants makes the API seems sooo legacy.

Finally, what is a meaning of those parameters in Java EE environment? JavaDoc says that acknowledgeMode is ignored if the session is transacted.

What does it all means? Nothing less than: those arguments doesn’t have any sense for JMS producer used in Java EE context. That’s why they encourage you to use (true, 0) parameter values to avoid unnecessary confusion.

This smells of legacy.

Ok, but let’s get back to the main subject. I wanted to take a look what’s new in JMS world and how it allows me to code easier and in more maintainable way. I’ve prepared a simple web application that uses JMS 2.0, JAX-RS and EJB (SLSB and MDB) and pushed it to my github repository here.

Continue reading →

Despite the fact that EJB inheritance sometimes uses Java inheritance — they’re not always the same. Just as you could read in my previous post, EJB doesn’t have to implement any interface to expose a business interface.
The other way around is also true — just because EJB is implementing some interface or extending other EJB doesn’t mean it exposes all or any of its views.

Let’s say we want to have some basic EJB exposing remote business interface. We then want to extend this EJB and override remote business methods.
Nothing fancy, right? But let’s take a look at some examples.

Continue reading →

This post will talk about possible ways of defining EJB views using annotations (I’ll just mention about using EJB Deployment Descriptor at the end.) I’ll focus on the most current EJB 3.1 views omitting legacy local, remote and home interfaces. Therefore, we can choose between:

remote business interface view,
local business interface view,
no-interface view.

I won’t discuss functional differences between those views but rather focus on possible ways of defining them.

Continue reading →

Let’s start with a short quiz. TxMergeBean is a SLSB that uses CMT and EntityManager. Assume the following local and remote business interfaces:

public interface TxMergeCommon {
    void methodA();
    void methodB(MeineEntity entity);
}

@Local
public interface TxMergeLocal {}

@Remote
public interface TxMergeRemote {}

and the following SLSB:

@Stateless
public class TxMergeBean implements TxMergeRemote, TxMergeLocal {

    @PersistenceContext
    private EntityManager em;

    @EJB
    private TxMergeLocal self;

    @Resource
    private SessionContext sctx;

    public void methodA() {
        MeineEntity entity = new MeineEntity("methodA");
        em.persist(entity);

        self.methodB(entity);
    }

    @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
    public void methodB(final MeineEntity entity) {
        entity.setName("methodB");
        em.merge(entity);

        sctx.setRollbackOnly();
    }
}

Assume that MeineEntity is properly defined and its only constructor parameter is saved as ‘name’ attribute.

What will be the database persisted value of MeinEntity ‘name’ attribute after TxMergeBean#methodA() invocation?

Continue reading →

Being in EJB and JPA world using CMT (Container Managed Transactions) is very comfortable. Just define few annotations to demarcate transaction boundary (or use the defaults) and that’s it – no fiddling with manual begin, commit or rollback operations.
One way to rollback your transaction is to throw non-application exception (or application exception with rollback = true) from your EJB’s business method.

It seems simple: if during some operation there is a possibility that an exception will be thrown and you don’t want to rollback your tx than you should just catch this exception and you’re fine. You can now retry the volatile operation once again within the same, still active transaction.

Now its all true for application exceptions thrown from user’s components. The question is – what with exceptions thrown from other components? Like JPA’s EntityManager throwing a PersistenceException?

And that’s where the story begins.

Continue reading →

JGroups is Bela Ban‘s piece of software for reliable message exchange that is highly configurable and can use either TCP or UDP as a transport protocol. Basically – you run the JGroups on number of clients, they form a cluster and they can send and receive messages within the cluster.

JGroups is used internally by JBoss Infinispan. Infinispan, however, unlike JGroups adds the distributed cache semantics (replicated / distributed modes, entries invalidation, transactional behavior, Map access API, etc.) It even allows you to use the cluster as a compute grid.

Infinispan in turn is used to provide JBoss AS 7 clustering functionalities. Therefore, it means that the underlying JGroups subsystem can and is configured using a standard JBoss AS 7 standalone*.xml file. You can access Infinispan cache from your Java EE component (e.g. EJB) without any problems as described here.

However, there are cases when you’d like to use just the underlying JGroups messaging instead of all the cache semantics Infinispan gives you. And here’s the place things are becoming more complicated. You can always use JGroups directly and store the configuration for it as an application-local resources. It might become arguable if this is or isn’t a violation of the Java EE spec which says that an application should not manage low-level connections, spawn threads, open sockets, etc. This is something that is better to be left to the application server – it also allows us to use one configuration file instead of spreading it across multiple places.

So, the question is – how to access the JGroups subsystem from our EJB application? The whole solution involves few steps which will be described below.

Continue reading →

JPA specification defines few types of EntityManagers / Persistence Contexts. We can have:

extended and transactional-scoped EntityManagers,
container-managed or application-managed EntityManagers.
JTA or resource-local EntityManager,

Besides the above distinction, we also have two main contexts in which EntityManager / Persistence Context can exist – Java EE and Java SE. Not every option is available for Java EE and not every is possible in Java SE. In the rest of the post I refer to the Java EE environment.

Ok, so before we’ll proceed to the real topic of this post — which is the behaviour of the EntityManager in Java EE created manually using EntityManagerFactory — let’s just shortly describe the above EM types.

Continue reading →

This post describes some of the pitfalls when coping with intercommunication between different modules (EAR, WAR, EJB-JAR) deployed in the same Java EE 6 Application Server.

The problem

The problem is as follows: you have two modules (let’s take the EARs as an example) that are deployed in the same JVM / Application Server: App1.ear and App2.ear.

App1.ear contains:

service.jar; it’s an EJB-JAR with the business logic of the application,
service-api.jar; it’s an API for the service.jar, so the EJB’s in service.jar must implement this API.

App2.ear contains:

client.jar; it’s the EJB-JAR with the business logic of the client application,
service-api.jar; it’s the same API / interfaces as in App1.ear/service-api.jar. It’s here because you will need to know the API of the service.jar if you want to communicate with it.

Continue reading →