Singleton vs Stateless beans in the architecture of a Java EE application

Question

A part of business logic at the core of my project has to perform a search on linked-data. Currently, I have implemented this part using a singleton session bean like this (SPARQL is a query language on RDF models which are constructed using linked data).

@Singleton
@Startup
public class SparqlEngine {

    @PostConstruct
    private void init() {
        // Initialiaze the model by connecting to the database
    }

    public ResultSet searchBySparql(String sparqlQuery) {
        // Perform the search on the model which is stored in the database
    }

    @PreDestroy
    private void cleanup() {
        // Close database connection
    }

}

This EJB is exposed to the other parts of my application by another EJB named SparqlEndpoint which is responsible for converting the ResultSet to a more comfortable SearchResult object which contains the model in a string form with the syntax specified by the client, total number of results and other metadata. The SparqlEndpoint EJB is simply @Stateless and has a local interface which is used by the clients. These clients include JSF managed beans and a couple of EJBs which expose it as SOAP and RESTful web services.

This is the most reasonable architecture that came to my mind, but I need to know if I have done it right. Should I use a Singleton bean to implement the core as I'm doing now, or a Stateless session bean is more appropriate? The database connection initialization usually takes a couple of seconds at least, and it may be useful to note than the it is a NoSQL one and does not support transactions. I'm not planning to add anything such as a write method to this bean. Is it correct for other EJBs to be stateless? If I want to expose my indexing engine (which performs writes on the database) as another EJB, how should I implement it?

Thanks in advance.

Answer 1

..I thought it may be a good idea to do it once at the time of deployment and let a singleton handle all database access tasks on an already initialized model (it is critical for the application to respond to queries fast)...

Connection management to DB should not be doe manually inside a SLSB. You should look at leveraging Datasource api. Managing network resources (e.g. DB connection etc) is best left to App server - especially in a container managed environment like the one you have. App Server initializes and maintains a pool of connections.

... The Endpoint EJB may have other tasks in the future which are not much related to the actual engine. Finally, also the web service EJB is subject to additions in the future...

You have used the word future twice in this comment. This is speculation and introduces Accidential Complexity. You can always re-factor when the need arises. Aim to Keep it simple. Designing and coding for future is always expensive..

..dump file and is used in testing environment where our NoSQL cluster is not available...

Why not use a good mocking framework instead of using dump file? Unit testing should not be environment dependent

Answer 2

It is easy, with singleton you can easier handle the issues with concurrent access to your resources. You can use container-managed concurrency or bean-managed concurrency.

With using a stateless session bean you will get the performance, EJB container creates a pool of many instances of those stateless beans and lends them to clients when the requests are coming. I.e. better for multi-user access.