Abstract: Multiple application server instances can be arranged in a cluster that implements a distributed EJB timer system. A high availability database can store EJB timer info. The EJB timer jobs can be distributed among the application server instances of the cluster that implement the distributed EJB timer system. In case of a failure of an application server instance, the EJB timer info can be used to reassign the EJB timer jobs associated with the failed application server instance.

Abstract: A system for determining when an EJB compiler needs to be executed, comprising: a server, including an EJB or plurality of EJBs and an EJB compiler operating thereon that determines a first snapshot of the EJB at a particular moment in time or for a particular server version, and a second snapshot of said EJB at a later moment in time or a subsequent server version, and compares the first and second snapshots to determine whether the EJB should be recompiled.

Abstract: The present invention supports container-provided EJB timer service that allows EJB instances dealing with timed events to create and register for a timer, which is scheduled to send notifications either at a specific time and/or after a specific elapsed duration, or at specific recurring intervals. When the timer expires, certain business logic inside the EJB instance will be invoked to handle the timeout event. When the cancel method of a timer is called, the timer may cease to exist. The timer is capable of retrying failed timeout under certain conditions when the current invocation of timeout logic fails. In addition, the timer is capable of monitoring the access from multiple registered EJB instances enrolled in transactions under multi-threaded environment, and restricting the access to the timer from EJB instances in certain threads until the current transaction accessing the timer commits to prevent a potential conflicting situation.

Abstract: A user can generate queries dynamically at runtime without having to redeploy the appropriate EJB or hard-code the query into the user application. A properties object can be generated to accept the query settings from the user. These settings can be extracted at runtime when the appropriate finder method is invoked, such that the desired query statement, such as a SQL statement, can be generated and executed against the database. This description is not intended to be a complete description of, or limit the scope of, the invention. Other features, aspects, and objects of the invention can be obtained from a review of the specification, the figures, and the claims.

Abstract: A user can generate queries dynamically at runtime without having to redeploy the appropriate EJB or hard-code the query into the user application. A properties object can be generated to accept the query settings from the user. These settings can be extracted at runtime when the appropriate finder method is invoked, such that the desired query statement, such as a SQL statement, can be generated and executed against the database. This description is not intended to be a complete description of, or limit the scope of, the invention. Other features, aspects, and objects of the invention can be obtained from a review of the specification, the figures, and the claims.

Abstract: A cursored collection can be used to allow a user to view subsets of a data result set, thereby conserving system resources. A persistence manager can execute SQL statements on a database, receive a result set from the database, and populate a set of EJBs with the result set. This can be a full result set, or a subset of the full result set. A bean manager can allow the user to access all the EJBs or a subset of the EJBs. The bean manager can also provide the user with a list of EJBs and let the client select the EJBs to access. The client can then iterate through the result set, either by viewing different subsets or selecting different EJBs from the list. This iterative process can continue until all the results have been viewed or the client does not wish to access any more results from the set.

Abstract: A system for determining when an EJB compiler needs to be executed, comprising: a server, including an EJB or plurality of EJBs and an EJB compiler operating thereon that determines a first snapshot of the EJB at a particular moment in time or for a particular server version, and a second snapshot of said EJB at a later moment in time or a subsequent server version, and compares the first and second snapshots to determine whether the EJB should be recompiled.

Abstract: Multiple application server instances can be arranged in a cluster that implements a distributed EJB timer system. A high availability database can store EJB timer info. The EJB timer jobs can be distributed among the application server instances of the cluster that implement the distributed EJB timer system. In case of a failure of an application server instance, the EJB timer info can be used to reassign the EJB timer jobs associated with the failed application server instance.

Abstract: A system for determining when an EJB compiler needs to be executed, comprising: a server, including an EJB or plurality of EJBs and an EJB compiler operating thereon; and, a logic that determines a first snapshot of the EJB at a particular moment in time or for a particular server version, and a second snapshot of said EJB at a later moment in time or a subsequent server version, and compares the first and second snapshots to determine whether the EJB should be recompiled.

Abstract: A user can generate queries dynamically at runtime without having to redeploy the appropriate EJB or hard-code the query into the user application. A properties object can be generated to accept the query settings from the user. These settings can be extracted at runtime when the appropriate finder method is invoked, such that the desired query statement, such as a SQL statement, can be generated and executed against the database. This description is not intended to be a complete description of, or limit the scope of, the invention. Other features, aspects, and objects of the invention can be obtained from a review of the specification, the figures, and the claims.

Abstract: A user can generate queries dynamically at runtime without having to redeploy the appropriate EJB or hard-code the query into the user application. A properties object can be generated to accept the query settings from the user. These settings can be extracted at runtime when the appropriate finder method is invoked, such that the desired query statement, such as a SQL statement, can be generated and executed against the database. This description is not intended to be a complete description of, or limit the scope of, the invention. Other features, aspects, and objects of the invention can be obtained from a review of the specification, the figures, and the claims.

Abstract: A system and method for EJB classloading. By changing the EJB classloading scheme so that the EJB impl class is loaded in a child ClassLoader, the system allows the old EJB impl class to be replaced with a new one without disturbing the rest of the deployment. The key to doing this is to remove all direct references to the EJB impl class from classes loaded in the parent ClassLoaders. Removing this dependency allows the old EJB impl class to be replaced at any time with a new impl class.

Abstract: The present invention supports container-provided EJB timer service that allows EJB instances dealing with timed events to create and register for a timer, which is scheduled to send notifications either at a specific time and/or after a specific elapsed duration, or at specific recurring intervals. When the timer expires, certain business logic inside the EJB instance will be invoked to handle the timeout event. When the cancel method of a timer is called, the timer may cease to exist. The timer is capable of retrying failed timeout under certain conditions when the current invocation of timeout logic fails. In addition, the timer is capable of monitoring the access from multiple registered EJB instances enrolled in transactions under multi-threaded environment, and restricting the access to the timer from EJB instances in certain threads until the current transaction accessing the timer commits to prevent a potential conflicting situation.

Abstract: A system and method for EJB classloading. By changing the EJB classloading scheme so that the EJB impl class is loaded in a child ClassLoader, the system allows the old EJB impl class to be replaced with a new one without disturbing the rest of the deployment. The key to doing this is to remove all direct references to the EJB impl class from classes loaded in the parent ClassLoaders. Removing this dependency allows the old EJB impl class to be replaced at any time with a new impl class.

Abstract: A system for determining when an EJB compiler needs to be executed, comprising: a server, including an EJB or plurality of EJBs and an EJB compiler operating thereon; and, a logic that determines a first snapshot of the EJB at a particular moment in time or for a particular server version, and a second snapshot of said EJB at a later moment in time or a subsequent server version, and compares the first and second snapshots to determine whether the EJB should be recompiled.

Abstract: A cursored collection can be used to allow a user to view subsets of a data result set, thereby conserving system resources. A persistence manager can execute SQL statements on a database, receive a result set from the database, and populate a set of EJBs with the result set. This can be a full result set, or a subset of the full result set. A bean manager can allow the user to access all the EJBs or a subset of the EJBs. The bean manager can also provide the user with a list of EJBs and let the client select the EJBs to access. The client can then iterate through the result set, either by viewing different subsets or selecting different EJBs from the list. This iterative process can continue until all the results have been viewed or the client does not wish to access any more results from the set.

Abstract: A user can generate queries dynamically at runtime without having to redeploy the appropriate EJB or hard-code the query into the user application. A properties object can be generated to accept the query settings from the user. These settings can be extracted at runtime when the appropriate finder method is invoked, such that the desired query statement, such as a SQL statement, can be generated and executed against the database.