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.

What is the rationale for making the SparqlEngine EJB a Singleton? What benefits are you getting by having just one bean per EJB container? Why create additional SLSB for returning SearchResult? Why not add a method to this Engine SLSB to return the transformation? — basav, Aug 30 '12 at 15:11
I actually do not have solid reasons for designing the architecture like this, and I'm not sure about it being the best way either. Since the initialization is not a trivial task and takes time, 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). — Arash Shahkar, Aug 30 '12 at 15:31
I introduced the Endpoint to do some sort of loose coupling and separation of concerns. There is actually a SparqlEngineLite EJB which initializes the model using a dump file and is used in testing environment where our NoSQL cluster is not available. 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. However, all this is just my own way of thinking and it would be of much pleasure if anyone can guide me to achieve a better one. — Arash Shahkar, Aug 30 '12 at 15:35

score 2 · Answer 1 · answered Aug 30 '12 at 19:05

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.

score 1 · Accepted Answer · edited May 23 '17 at 11:51

..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

Thank you for your answer. I took a look at HBase's JDBC driver and will investigate letting the app server manage our HBase connection. However, the library I am using leverages HBase's own API and I'm not sure I can make it connect using the datasource glassfish provides. If it's the case, what do you think is the better way? A singleton bean or a stateless bean? And about the future, that points to the next week or so. I'm pretty sure each of these EJBs become much more thick very soon. The mocking framework is also a very good suggestion. I will investigate it. Thanks again. — Arash Shahkar, Aug 30 '12 at 18:33
see if you use Apache DBCP to pool your connections - http://commons.apache.org/dbcp/ — basav, Aug 30 '12 at 18:38

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

2 Answers2