Hello my dear friends.

In this video, we will examine the Singleton Session Bean. So, let's begin. A singleton bean is a session bean that is instantiated once per application. It ensures that only one instance of a class exists in the whole application and provides a global point of access to it. There are many situations where singleton objects are needed, that is, where your application only needs one instance of an object: a mouse, a window manager, a printer spooler, a file system, and so on. Another common use case is a caching system whereby the entire application shares a single cache to store objects. Another common use case is a caching system whereby the entire application shares a single cache to store objects. Singleton Session Beans offer similar functionality to stateless session beans, but differ from them in that there is only one Singleton Session Bean per application as opposed to a pool of stateless session beans, any of which may respond to a client request. Like stateless session beans, Singleton Session Beans can implement web service endpoints.

Singleton Session Beans maintain their state between client invocations, but are not required to maintain their state across server crashes or shutdowns. In an application managed environment, you need to tweak your code a little bit to turn a class into a singleton. You need to prevent the creation of a new instance by having a private constructor. The public static method getInstance returns the single instance of the cache singleton class. If a client class wants to add an object to the cache using the singleton, it needs to call CacheSingleton.getInstance.addToCache() method. If you want this code to be thread safe, you will have to use the synchronized keyword to prevent thread interference and inconsistent data. Applications that use a Singleton Session Bean may specify that the singleton should be instantiated upon application startup, which allows the singleton to perform initialization tasks for the application. The singleton may perform cleanup tasks on application shutdown as well because the singleton will operate throughout the lifecycle of the application. Now, let's examine the lifecycle of Singleton Session Bean.

Like a stateless session bean, a Singleton Session Bean is never passivated and has only two stages: non-existent and ready for the invocation of business methods. The EJB container initiates the Singleton Session Bean lifecycle by creating the singleton instance. This occurs upon application deployment if the singleton is annotated with a startup annotation, the container performs any dependency injection and then invokes the method annotated PostConstruct if it exists. The Singleton Session Bean is now ready to have its business methods invoked by the client. At the end of the lifecycle, the EJB container calls the method annotated PreDestroy if it exists. The Singleton Session Bean is now ready for garbage collection. Now, let's examine the creation of Singleton Session Bean with this code. Look, we have a start in Singleton annotations. Also, we use PostConstruct annotation.

This means EJB will run PostConstruct method after dependency injections if it exists. When you deploy the EJB application, the EJB container will initialize the singleton and this could be seen in the logs like this. Done. Now, we have finished session beans. In the next video, we will examine the message-driven beans. I'll see you in the following video.