@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)

@TransactionTimeout(60)

Class - SyncToProdImpl

public void mergeCompanies(List<Company> currentSelectedCompanies, String companyName)

@Inject

@PostConstruct

@Remote

Declares the remote business interface(s) for a session bean.

The Remote annotation is applied to the session bean class or remote business interface to designate a remote business interface of the bean.

When used on an interface, designates that interface as a remote business interface. In this case, no value element should be provided.

The Remote annotation applies only to session beans and their interfaces.

A session bean is not persistent.  (That is, its data is not saved to a database.)

EJB - Stateless BeanA stateless session bean is a type of enterprise bean which is normally used to do independent operations. A stateless session bean as per its name does not have any associated client state, but it may preserve its instance state. EJB Container normally creates a pool of few stateless bean's objects and use these objects to process client's request. Because of pool, instance variable values are not guaranteed to be same across lookups/method calls.

Following are the steps required to create a stateless ejb.

Create a remote/local interface exposing the business methods.

This interface will be used by the ejb client application.

Use @Local annotation if ejb client is in same environment where ejb session bean is to

be deployed.

Use @Remote annotation if ejb client is in different environment where ejb session bean

is to be deployed.

Create a stateless session bean implementing the above interface.

Use @Stateless annotation to signify it a stateless bean. EJB Container automatically

creates the relevant configurations or interfaces required by reading this annotation

during deployment.

@ManagedBean

Managed Bean is a regular Java Bean class registered with JSF. In other words,

Managed Beans is a java bean managed by JSF framework.

The managed bean contains the getter and setter methods, business logic or even a

backing bean (a bean contains all the HTML form value).

Managed beans works as Model for UI component.

Managed Bean can be accessed from JSF page.

From JSF 2.0 onwards, Managed beans can be easily registered using annotations. This

approach keeps beans and there registration at one place and it becomes easier to

manage.

Views

Local view is the interface you want to expose to local clients.

Remote View is the interface you want to expose for remote clients, perhaps with less functionality.

No interface view, I believe, is just automatically generates an EJB view based on the methods of the class.

The "view" is what is going to be exposed based on the EJB lookup.

Remote client viewWhen your EJB and its clients will be in a distributed environment - meaning EJBs and clients will reside on separate Java virtual machines. Example : EJBs hosted on a

WebSphere Application Server and Servlets that consume EJB APIs hosted on a Tomcat server.

Local client viewOnly when it is guaranteed that other enterprise beans or clients will only address the bean within a single JVM. Example, EJBs as well as the Servlets deployed on the same WebSphere server.

No-Interface viewIs almost same as local client view, but there are differences. Your bean class is not required to implement client view interfaces in this case. All public methods of the bean class are automatically exposed to the caller. no-interface view always acquires an EJB reference - just like local or remote views - either through injection or JNDI lookup; but, Java type of the EJB reference is the bean class type rather than the type of a local interface. This is a convenience introduced as part of Java EE6.

Difference between local client view and no-interface viewIn case of no-interface view, the client and the target bean must be packaged in the same application (EAR). In case of local view, client can be packaged in a separate application than the enterprise application. So, this gives more flexibility in terms of fine-graining your components.

You may use local client view vs no-interface view depending on your API usage scenario. It is very likely for no-interface view to receive flexible features in future specs.