Develop Reference

Are ReaderInterceptor, WriterInterceptor thread safe?

I want to invoke stateless EJB from ReaderInterceptor, WriterInterceptor but I'm not sure is this interceptors can I inject EJB or I need every time lookup EJB?

Specification jax-rs 2.0 say nothing about creating instance for each request. So, it's not thread safe

§6.4 of the JAX-RS 2.0 specification states:
... a single instance of each filter or entity interceptor is instantiated for each JAX-RS application. ...
Therefore your interceptor is by definition a singleton. However, the injection point for your EJB will consist of a proxy that takes care of providing access to an unused instance of the stateless EJB each time it is invoked. It may find it in a pool of pre-created instances or it may just create and initialise a new one.
Additionally, §4.10.13 "Non-reentrant Instances" of the EJB 3.2 specification states that:
The container must ensure that only one thread can be executing a stateless or stateful session bean instance at any time. Therefore, stateful and stateless session beans do not have to be coded as reentrant. ...
In summary, just inject your EJB. The container will look after thread safety issues on your behalf.

Will a TransactionAttributeType.REQUIRES_NEW annotated method run on a new Thread?

According to documentation, in container managed transactions, if a method is annotated with TransactionAttributeType.REQUIRES_NEW attribute, will suspend any client transaction, delegate the call to this method/ create a new transaction, and resume to previous transactions after the new one has been completed.
So this actually means, that no new thread is created, and that the previous transaction is on a "wait" state until the new one is has been finished?

As stated in the Java-Doc:
If a client calls with a transaction context, the container suspends the association of the transaction context with the current thread before starting the new transaction and invoking the method. The container resumes the suspended transaction association after the method and the new transaction have been completed.
It's not abandoning the thread or creating a new one, it's only releasing the association to the transaction and recreating it afterwards. If it would create a new thread, there would be no need to remove the association because it was never made.

Container managed transactions means JTA and JTA specifications does not allow transactions to span across multiple threads. Each JTA transaction is associated with an execution thread, so it means that at most one transaction can be active at any given time. Note that multiple transactions can be associated with a single thread, but again only one can ever be active at a given time.
As JTA does not support nested transactions, it means that if one transaction is active, it is not possible to start another one in the same thread, until the first transaction commits or rolled back (or timed out, causing again rollback), thus releasing transaction association with the current thread.
What happens behind the scenes when method with transactional attribute REQUIRES_NEW is called with the transactional context? First, JTA temporarily suspends the transaction that is currently associated with the calling thread by calling it is internal API, particularly it calls TransactionManager.suspend(). (If calling thread is not associated with any transaction (i.e. method was called with transactional attribute of NOT_SUPPORTED or without transactional context) a null object reference is returned) and obtaining Transaction object. This Transaction object will be passed to TransactionManager.resume() method to re-associate the transaction context with the calling thread once above mentioned REQUIRES_NEW method completes. Whether on same or another thread depends on JTA implementation, as specification does explicitly require it to be one way or the other.
Answering your question - the only way for JTA to fulfill transactional attribute REQUIRES_NEW when called in transactional context is to suspend the transaction from a thread and resume it later on the same or another thread. When it will be resumed? Remember that REQUIRES_NEW attribute basically means is that annotated method always have to be in its OWN TRANSACTION, which in turn means that the method should be committed or rolled back independently of methods further up the call stack. Suspended transaction will be resumed, once called method with transactional attribute REQUIRES_NEW commits or rolled back.
As a side notes, as you may probably know, there is no way for Bean Managed Transaction to suspend a transaction, you can't do it programatically. Only JTA can do this using an it's internal transaction management API and you can achieve this declaratively by using CMT and transaction attributes. Also note that this attribute can lead to excessive transaction overheads is overused.

CDI Event and XA transaction

I'm using Java EE 6.
I'd like to trigger an action upon successful commit of a transaction. For now, my plan is to use a CDI transactional event within an EJB:
#Asynchronous
public void triggerAction(#Observes(during = TransactionPhase.AFTER_SUCCESS) MyEvent myEvent){
// Do something with the event
}
The transaction triggering the event can be involved in a XA distributed transaction.
At which phase of the two phase commit will the observer be called ?
The documentation states:
An after success observer method is called during the after completion phase of the transaction, only when the transaction completes successfully.
I'm not sure what this implies when using distributed transactions.
Further, is there any warranty that the data is already in DB (i.e. can my observer method be called when the decision to commit is reached, but the data are not yet persisted in DB ?).

Unfortunately, CDI 1.x does not define the behavior of events in async call stacks. The behavior you will see will be container specific, including some containers that invoke this method synchronously instead of async. CDI 2.0 is introducing an async observer for events.

the XA transaction manager is responsible for 'applying' XA semantics, meaning it has to go through the 2 Phase Commit (dialog) with all the involved parties (distributed parties) and then it will commit and consider (if no errors) it as done.
In you case, the observer will be called when the data in the db will be commited in the context of the transaction and not in any previous or interim state.

EJB : Two stateless objects use two different transaction

I would like to ask question regarding EJB. I am using eclipselink of JPA.
There is two stateless objects in a stateless object in my code.
Is that possible this two stateless object use two different transactions?

Absolutely. You may find it useful to read about the transaction attributes.
If the called method in your first class (say StatelessFirst) has a transaction type REQUIRED (the default) or REQUIRES_NEW, when it is called it will initiate a new transaction. If this then calls a method in your second class (say StatelessSecond) with transaction type REQUIRES_NEW, the first transaction is suspended and a second transaction is initiated while the second method executes. When the method in StatelessSecond completes, the second transaction commits, the first transaction is reinstated, and control is passed back to StatelessFirst.
To make the first transaction commit before StatelessSecond is called, you can use bean-managed transactions. This gives you full control over the transaction management, so in StatelessFirst you can begin a transaction, then commit then call StatelessSecond. If you go with this approach, note that you can't perform nested transactions in BMT.
One other option which allows you to stay within CMT would be to pull the transactional behaviour out of StatelessFirst into a third EJB, with REQUIRES_NEW. Then the pattern is:
Client calls StatelessFirst, which initiates transaction A
StatelessFirst calls NewBean, which initiates transaction B, and performs some work
NewBean commits transaction B and returns
StatelessFirst calls StatelessSecond, which initiates transaction C, and performs its work
StatelessSecond commits transaction C and returns
StatelessFirst completes, and commits transaction A (which doesn't have any changes anyway)

EJB Service Locator with caching

I am using a Service Locator implementation which caches the result of javax.naming.Context#lookup call, and maps it to the requested EJB interface, so all subsequent requests (for the same EJB) after the first one, return the cached instance.
My concerns are:
Since the same instance is used, there is no utilization of the
server EJB pool which would serve multiple simultaneous requests
with multiple EJBs (unless the underlying server logic somehow makes
use of the EJB pooling)
Stateless and stateful EJBs are thread safe, but since, again,
only one instance per EJB class is used, and EJB has EntityManager
injected via #PersistenceContext, I assume that means that multiple
threads could be using the same EntityManager instance (not just the
persistence context), which definitely is not thread-safe
Do you think that it's best not to use caching in the Service Locator, or that my concerns are unjustified regarding EJB behavior?

What you get from the lookup operation (through the JNDI service) is an object called Stub and him is not fixed with any special EJB instance.
Once cached, every time you invoke an EJB service the stub is able to select a different EJB instance from the pool (this apply to stateless); even in a cluster environment, the stub object is able to select an EJB instance from different servers.
Therefore, caching the stub object should not be a problem.
Notice that I'm talking about stateless, I think that caching doesn't make sense to statefull session bean.
The EJB lookup is a time-consuming operation, so caching improves the client performance.
About your comment:
If you were using EntityManager inside a component that is used by multiple concurrent threads like a Servlet, yes, you will have to care about concurrency, but the EJB's Tread Model imply that will not be several thread using the same EntityManager instance at the same time, so the fact that EM is not thread safe doesn't matter.
What concerns me still is the fact that different EJBs are using the
same injected (via #PersistenceContext) EntityManager instance
I think that for simple sceneries the best way to think about it, if as describe here:
The most common pattern in a multi-user client/server application is
entitymanager-per-request. In this model, a request from the client is
send to the server (where the JPA persistence layer runs), a new
EntityManager is opened, and all database operations are executed in
this unit of work. Once the work has been completed (and the response
for the client has been prepared), the persistence context is flushed
and closed, as well as the entity manager object.
This will be more difficult to check ;)