Hello dear friends. In this video we will examine the singleton session being let's begin. A singleton bean is a session being 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 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 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 life cycle of singleton session bean. Like a stateless session being, 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 being lifecycle 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 annotatedPostConstruct() 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 AnnotatedPreDestroy() 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 post construct annotation. This means EJB will run post construct 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.