Stateless Session Bean - Stopping Multiple Calls

Question

So I read from this post from BalusC about how to stop a stateless session bean from continually thrashing a data store (e.g. DB) when accessed by JSF (which may/will make multiple calls) and so I've implemented my code in what I'd like to think is in the spirit of what was posted by BalusC (and other forums posts from "best practices" I've seen concerning this issue).

My stateless session bean looks like this:

@Stateless
@Named("productsService")
public class ProductService {

    private static boolean changed = true;

    private List<Product> products;

    private long count;

    @PersistenceContext(name = "myPU")
    private EntityManager em;

    @Inject
    private Product product;

    public ProductService() {
    }

    private void productRecordsFromDB() {
        products = em.createNamedQuery("Product.getAll", Product.class).getResultList();
        Object o = em.createNamedQuery("Product.getCount", Product.class).getSingleResult();
        count = ((Long) o).longValue();
    }

    public void addProduct() {
        synchronized (ProductService.class) {
            changed = true;
            em.persist(product);
        }
    }

    public long countProducts() {
        return count;
    }

    public void removeProduct(Product p) {
        synchronized (ProductService.class) {
            changed = true;
            em.remove(em.merge(p));
        }
    }

    public int removeAllProducts() {
        synchronized (ProductService.class) {
            changed = true;
            return em.createNamedQuery("Product.deleteAll").executeUpdate();
        }
    }

    public List<Product> getProducts() {
        synchronized (ProductService.class) {
            if (changed) {
                productRecordsFromDB();
                changed = false;
            }
        return products;
        }
    }

    public Product getProduct() {
        return product;
    }

    public void setProduct(Product p) {
        product = p;
    }
}

EDIT: I've added the synchronized block to the relevant portions to ensure serial access although this is now starting to feel more like a singleton. I'm still curious to know how others have dealt with this issue pertaining to multiple calls to a data store.

Specifically, I've created a 'dirty' flag that is checked and if the DB has been updated then the dirty flag is set to true (via updates to the DB). After detection of the dirty flag, it's set back to false and so only one call to the DB is made. Hence, no DB thrashing ensues.

My question is: what I've done, is this an appropriate "best practice" to solve the solution or is there a more clever way that I am not aware of? I'm kind of thinking in terms of the old 'J2EE' blue print design patterns as well as a possible annotation that I may be missing within the context of Java EE 6.

Answer 1

is this an appropriate "best practice" to solve the solution or is there a more clever way that I am not aware of?

The way in which you've build your session bean is unfortunately not a best practice. In fact, as Mikko explained, it's completely anti to how a session bean should normally work. So, despite your obvious efforts I'm afraid what you created is a prime example of a bad practice. It almost does everything one should not do in a stateless session bean.

In order to solve the problem BalusC outlined, you can use a separate backing bean to which your view binds instead of letting it directly bind to a service. This backing then is the bean that caches a result during a request or for the duration of a view scope.

E.g.

The Service:

@Stateless
public class ProductService {

    @PersistenceContext(name = "myPU")
    private EntityManager em;

    public List<Product> getProducts() {
        em.createNamedQuery("Product.getAll", Product.class).getResultList();
    }

    // ...
}

Then the backing bean (if using CDI, add @ViewScoped annotation via e.g. CODI):

@ViewScoped
@ManagedBean
public class SomeBacking {

    private List<Product> products;

    @EJB
    ProductService productService;

    @PostConstruct
    public void init() {
        products = productService.getProducts();
    }

    public List<Product> getProducts() {
        return products;
    }
}

I've placed the call to the service is a @PostConstruct here, but depending on your exact requirements this could of course also be in an action method or via the lazy-loaded pattern in the getter.

Answer 2

You have two main problems:

1. state is shared between threads without guarding with lock
2. stateless beans have state visible to client.

You share state between all instances of ProductService via static changed variable. However, reads and writes to this variable are not synchronized. As result there is no guarantee that instances share same value for changed. You have to control access via lock (synchronize with same lock) or in minimum make it volatile (just guarantees that you will see last written value).

Next problem is that stateless beans should not have state visible to client. That's why they are called stateless. It should make no difference to client which instance handles call, because client cannot control which instances is called. Think about for example following scenario (instances s1 and s2, assuming both are in fresh state):

1. s1.getProducts => changed = false
2. s2.getProducts => because changed is false, it will return null (no one set value to instance variable products for s2)

Answer to edited question and comment: You still have same problem with stateless vs. state. Stateless is used where solution without state does not fit in. As you see from following, it still matters which instance will handle business method call:

1. s1.getProducts => changed = false;
2. s2.getProducts => because changed is false, null is returned

Please follow approach Arjan Tijms offered, or something in same spirit at least.

Answer 3

This is by far the worst abuse of stateless session beans I've seen in a long time.

You have created a kind of Singleton, but in a bean that is absolutely not suited for this, with mixed concerns of global and local operations and the risks of dead locks by synchronizing on the class literal.

If you need a Singleton, you should use the dedicated @Singleton bean, but if you want to prevent the repeated calls from JSF during a request, use a backing bean like is shown in the other answer.

Answer 4

There's a concrete application for EJBs as singletons, examples Here. The EJB 3.0 Standard allows for timeshared, synchronized access to a single session bean. That being said you have the following options to prevent/control session caching.

1)A singleton EJB may maintain a local cache copy of database results that is refreshed on a schedule using an EJB 3.0 Timer bean, a ridiculously plain example Here. This singleton you could then inject into whatever context you please JSF managed bean, CDI bean etc

2)Alternatively, your specific usecase could cache it's own local copy of required data, which is read once at bean construction @PostConstruct although this paradigm is more applicable to a longer lived bean than a @RequestScoped bean.

3)Related to 2), have a @ApplicationScoped bean that functions similarly to 1) above but that now maintains a (huge)cache of various Lists