Take a look at the following code example:

The result of this code execution is:

INFO: [myMethod] Method parameter: 2
INFO: [myMethod] Context parameter: Context hello!

A request made to MyService#myMethod(-) will be intercepted by MyInterceptor which will add some contextual data (ctx.getContextData().put(ctxParamKey, "Context hello!")) and invoke the actual EJB.

The EJB (just as interceptor did – with help of SessionContext) will recover the value saved by the interceptor and can use it right away.

If the parameter wasn’t set, the null value will be returned. So if you’d comment this code: ctx.getContextData().put(ctxParamKey, "Context hello!") you can expect following results:

INFO: [myMethod] Method parameter: 2
INFO: [myMethod] Context parameter: null

In this way you can pass the contextual data to your EJB methods without changing their signature. Just remember not to overdose with this feature, as it makes testing and auditing more difficult.

The JPA provider provides an implementation of EntityManager – that’s obvious. More interesting is that the Application Server is scanning all @PersistenceContext fields and wrapping these EntityManagers into its own class – a proxy – which delegates requests to the JPA provider’s EntityManager. Therefore, if you’re comparing results of toString() method of such EntityManagers, you can’t say about PersistenceContexts equality but rather about Server Application EntityManager equality. Needless to say, an Application Server could use one proxy as an access point to different EntityManagers. Without knowing the internals, you’re not able to say how it will work and decide if your results are meaningful.

One of the ways to cope with this problem might be to unwrap the container-provided EntityManager proxy to get to the JPA-provided one. You can do that either using:
- EntityManager#getDelegate() which returns an Object (this is the depreciated way) or,
- EntityManager#unwrap(JPAProviderSpecificClass) which returns JPA-provider specific object (encouraged way).
In this way you’re one step closer to the victory.

On this point, it’s worth of noticing, that by the JPA specification, given Persistence Context, when used in transactional environment, is bound to exactly one transaction and is accessible from all components which participates in this transaction. So, maybe we could just compare if the transaction is the same and it would be enough to confirm that the PersistenceContexts are the same? You could check transactions for equality using TransactionSynchronizationRegistry#getTransactionKey().

Both situations: unwrapping of EntityManager and testing transactions for equality, have been presented in following code.

Moreover, this code shows one more, very important thing which might be hard to analyse. In order to invoke EJB call, you need to use it’s business interface. If you don’t do that, you’ll end invoking a local method call which doesn’t have any EJB nature – the container is not able to intercept such method invocation. Therefore, for local call, the @TransactionAttribute will have no meaning.

Take a look at the following code. I’m using EclipseLink and Glassfish 3.1.1. The client invokes method1().

Lets examine the exemplary results of the invocation:

INFO: [method1] Server proxy for EntityManager EM: com.sun.enterprise.container.common.impl.EntityManagerWrapper@173d62d

INFO: [method1] EclipseLink EntityManager: org.eclipse.persistence.internal.jpa.EntityManagerImpl@1f243df

INFO: [method1] Tx key: JavaEETransactionImpl: txId=45 nonXAResource=23 jtsTx=null localTxStatus=0 syncs=[com.sun.ejb.containers.ContainerSynchronization@462718, com.sun.enterprise.resource.pool.PoolManagerImpl$SynchronizationListener@1b0d75f]

INFO: [method2] Server proxy for EntityManager EM: com.sun.enterprise.container.common.impl.EntityManagerWrapper@10ba812

INFO: [method2] EclipseLink EntityManager: org.eclipse.persistence.internal.jpa.EntityManagerImpl@475614

INFO: [method2] Tx key: JavaEETransactionImpl: txId=46 nonXAResource=null jtsTx=null localTxStatus=0 syncs=[com.sun.ejb.containers.ContainerSynchronization@1644679]

INFO: [method2] Is Tx1 the same as Tx2? false

We have 2 separate transactions (result of comparison – false).
Application Server EntityManager wrappers — in method1() and method2() — represents different instances.
JPA provider EntityManagers also represents different instances.

Now let’s modify the code a bit and remove or comment the @TransactionAttribute fragment, so method2() will have a default Tx attribute – REQUIRED. In this case, it will reuse the transaction of method1(). Let’s look at the results:

INFO: [method1] Server proxy for EntityManager EM: com.sun.enterprise.container.common.impl.EntityManagerWrapper@178fd24

INFO: [method1] EclipseLink EntityManager: org.eclipse.persistence.internal.jpa.EntityManagerImpl@33517f

INFO: [method1] Tx key: JavaEETransactionImpl: txId=48 nonXAResource=95 jtsTx=null localTxStatus=0 syncs=[com.sun.ejb.containers.ContainerSynchronization@12b86b2, com.sun.enterprise.resource.pool.PoolManagerImpl$SynchronizationListener@985158]

INFO: [method2] Server proxy for EntityManager EM: com.sun.enterprise.container.common.impl.EntityManagerWrapper@469bc

INFO: [method2] EclipseLink EntityManager: org.eclipse.persistence.internal.jpa.EntityManagerImpl@33517f

INFO: [method2] Tx key: JavaEETransactionImpl: txId=48 nonXAResource=95 jtsTx=null localTxStatus=0 syncs=[com.sun.ejb.containers.ContainerSynchronization@12b86b2, com.sun.enterprise.resource.pool.PoolManagerImpl$SynchronizationListener@985158]

INFO: [method2] Is Tx1 the same as Tx2? true

We have 1 transaction (result of comparison – true).
Application Server EntityManager wrappers represents different instances.
Both JPA provider EntityManagers represents the same instance.

So, as you can see – only after unwrapping the container-provided EntityManager we were able to see that we, in fact, use the same EntityManager.

At the end, let’s see get back to the original code but change the invocation of method2() from method1() to be a local call, so we’ll be using myMethod2(txKey) instead of ctx.getBusinessObject(MyEJB.class).myMethod2(txKey). Exemplary results might be as follows:

INFO: [method1] Server proxy for EntityManager EM: com.sun.enterprise.container.common.impl.EntityManagerWrapper@110d926

INFO: [method1] EclipseLink EntityManager: org.eclipse.persistence.internal.jpa.EntityManagerImpl@12062da

INFO: [method1] Tx key: JavaEETransactionImpl: txId=50 nonXAResource=95 jtsTx=null localTxStatus=0 syncs=[com.sun.ejb.containers.ContainerSynchronization@139defe, com.sun.enterprise.resource.pool.PoolManagerImpl$SynchronizationListener@5f299d]

INFO: [method2] Server proxy for EntityManager EM: com.sun.enterprise.container.common.impl.EntityManagerWrapper@110d926

INFO: [method2] EclipseLink EntityManager: org.eclipse.persistence.internal.jpa.EntityManagerImpl@12062da

INFO: [method2] Tx key: JavaEETransactionImpl: txId=50 nonXAResource=95 jtsTx=null localTxStatus=0 syncs=[com.sun.ejb.containers.ContainerSynchronization@139defe, com.sun.enterprise.resource.pool.PoolManagerImpl$SynchronizationListener@5f299d]

INFO: [method2] Is Tx1 the same as Tx2? true

We have 1 transaction (result of comparison – true).
Both Application Server EntityManager wrappers represents the same instance.
Both JPA provider EntityManagers represents the same instance.

I hope this sum up what are possible situations you might bump into when using transactional, container-managed EntityManager.

The code snippet which I presented here can be found on my Gist.

References:
- EclipseLink Forum
- Glassfish mailing list

[remote "origin"]
	fetch = +refs/heads/*:refs/remotes/origin/*
	url = VALUE_WHICH_SHOULD_BE_ADJUSTED

Simple, easy, and most importantly – it works.

If you use CMT (Container Managed Transactions) you cannot use UserTransaction interface. Instead, you can manage your transaction through SessionContext interface. This interface gives you two places that hooks to the current transaction: setRollbackOnly(-) and getRollbackOnly().
But what if you would like to check the current transaction’s status?

Well, the first answer would be: think twice if you really need to do this.

The transaction is container managed, so get/setRollbackOnly(-) should be probably the most important methods for you.

However, if you still need to get some more detailed information about your CMT you can use the TransactionSynchronizationRegistry interface which (just like UserTransaction) can be fetched using JNDI or @Resource annotation:

@Resource
TransactionSynchronizationRegistry txReg;

txReg.getTransactionStatus();

Here you can find what the integer status returned by this method invocation means.

I’ve added entries to the Windows/System32/drivers/etc/hosts on my remote Windows 2008 Server. The entry was resolved properly as it could be tested from the command line (ping, telnet, etc.) but in IE and FF browsers it didn’t work.

DNS flushing, clearing browsers data or restart didn’t help a bit. It occurs that the IE had a proxy settings and apparently (when any proxy is set) it refuses to take hosts file under consideration. It affects not only IE but also the FF.

The solution was to remove the proxy setup in IE and from this moment the hosts file entries were resolved properly.

Wasted 2 hours of looking for the answer or issue in a glassfish-3.1 JIRA.

Did I mention I should always check the exact package of the imported class…?

ssh -X username@server

The -X flag is used to define the DISPLAY environmental variable on the remote host, so each X11 executed application will be forwarded to your machine.

uname -a

Unfortunately, it will return the kernel information only – no details about the distribution though.
The distribution info is located in a different file which is dependent on… the distribution itself. Check out the list of those filenames here.

As a majority of those files ends with “release” part, in most cases it should be enough to execute the following command:

cat /etc/*release

@Deployment
public static JavaArchive deploy() {

   // This is the classes and resources archive
   JavaArchive ar;
   ar = ShrinkWrap.create(JavaArchive.class, "resources.jar")
                  .addPackage(TestClass.class.getPackage());

   /*
    * The 'ar' archive will be added to the 'yourDir', so you'll
    * end with test.jar#/yourDir/TestClassPackage/TestClass.class
    */
   JavaArchive endArch;
   endArch = ShrinkWrap.create(JavaArchive.class, "test.jar")
                       .merge(ar, "yourDir");

   endArch.merge(ar, "yourDir");

   return endArch;
}

It does make a difference if you use *.war or *.jar for your deployment, so beware the following construct if it’s not exactly what you intended to do:

@Deployment
public static JavaArchive deploy() {
    JavaArchive ar;
    ar = ShrinkWrap.create(JavaArchive.class, "YourTests.war")
                   .addPackage(YourTestClass.class.getPackage());

    return ar;
}

In this case you can end with ClassNotFoundException for YourTestClass.
Just use the archive format you need (in this case I needed a *.jar and not a *.war) as this does make a difference for the application server.