Hello, dear friends. In this video, we will examine the singleton session bean. 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 schooler, a file system and so on. Another common use case is a cacheing 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 get instance, 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 life cycle of the application. Now, let's examine the life cycle 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 life cycle by creating the singleton instance. This occurs upon application deployment. If the singleton is annotated with the 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 life cycle, 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 used 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.