Anish Mathur

The EJB Timer Service is a container-provided service. Timer Service creates timers which call SLSB timout callback method.
Timers are not associated with a particular SLSB instance, as SLSB timeout callback method is called by container, if the bena crashes container can call the timeout on another bean instance.

Timers are managed and persisted by the container.
HTH
Anish Mathur

Bean Interceptors --> Method-Level Interceptors
is the correct one.

Default interceptors are triggered first, then the class-level interceptors and finally the method-level interceptor.

Yes, for stateful session beans, the interceptor instances are passivated upon bean instance passivation, and activated when bean instance is activated. Sec 12.2 in specifications.

Interceptor has PrePassivate & PostActivate callback methods these can be used to release and accquire the resources.

Have you declared the entity name in persitence.xml?

I tried both the EJB3 book example and solution suggested by Aleksander. The book example doesn't work but Aleksander's code works.

Now I am thinking if we do

Item refreshedItem = entityManager.merge(item);
.
.
long time consuming code
.
.
//decission is taken the item should be refreshed with the data from database
entityManager.refresh(refreshedItem);

Then as Lievaart said there is a chance that the object is merged, a flush occurs and the refresh reads the merged data and not the previous data.

The other way in which undo can be implemented is by using a find query based on primary key.

public Item undoItemChanges(Item item) {
Item refreshItem = em.createQuery("Select i from Item i where i.pkCol = :ItemPK")
.setParameter("ItemPK", item.pkCol).getSingleResult();
return refreshItem;
}

Just after writing this code I checked on net, I found following article
http://weblogs.java.net/blog/guruwons/archive/2006/09/understanding_t_1.html
check section "Getting fresh results from database"

In EJB 3 in Action sec 9.3.6
an example is given to undo changes made to Item entity and return fresh entity data from DB. The code to that is

<blockquote>code:

---

<pre name="code" class="core">public item undoItemChanges(Item item) {
entityManager.refresh(entityManager.merge(item));
return item;
}</pre>

---

</blockquote>

The merge operation is performed first in the undoItemChanges method because the refresh method only works on managed entities.

My doubt is, if the item object has been modified out the presitence context and then if merge operation is called, the changes made to Item object will be persisted to DB. Now, if refresh is called, it will get the modified data not the data which existed before calling merege. So, this method will not do the undo functionality.
Please help me in understanding how refresh and merge work in this example?

Check 14.2.4 of EJB in Action book.

For EJB 2 client view, which use create method on home interface to create EJb object instance, you can add a home interface.

Then use @RemoteHome annotation on the bean class to mark this as a remote home interface.

DI works only in container managed classes like EJB's, Servlets etc. Therefore, if you client is a managed class then only @EJB annotation can be used.

As per the specs section 17.3.1

The set of security roles used by the application is taken to be the aggregation of the security roles defined by the security role names used in the DeclareRoles and RolesAllowed annotations. The Bean Provider may augment the set of security roles defined for the application by annotations in this way by means of the security-role deployment descriptor element.

As per my understanding this means that the roles which are allowed to invoke a business method of a bean are
DeclaresRoles + RolesAllowed + security-role deployment descriptor.