Abstract: The present invention uses annotations and SQL to retrieve and/or persist POJO data from/to a database, respectively. Using SQL will enable developers to unleash the full querying power of their chosen Database Management Systems (DBMS) and will remove the requirement that they learn a new query language. A minimal amount of annotations will be associated in the same Java® source file where each class of POJO to be persisted to the database is defined. An enhanced compiler is capable of analyzing the annotated source file and automatically generates the bytecode required to create, deploy, and manage the persistence of POJOs without requiring knowledge of specific details of the persistence to corresponding data entities in the underlying database. Therefore, such an approach decreases the time, knowledge, skill and, ultimately, cost required to persist POJOs to an underlying database. This description is not intended to be a complete description of, or limit the scope of, the invention.

Abstract: Concurrency can be maintained in cluster caching when processing an update request on network server that is storing a local copy of a data item. The request can be processed using the local copy of the data item. A predicated update request can be sent to a network database storing the data item, wherein the database can commit the update if the local copy is current with the data item. If the local copy is not current, the network server can request a new copy, process the request using the current copy, and try another predicated request. The process can continue until the update is committed to the database or aborted. Once committed, any other servers in the cluster can be notified that the data item has been updated. Those other servers can drop any local copy of the data item and can request an updated copy of the data item.

Abstract: Transactions are granted concurrent access to a data item through the use of an optimistic concurrency algorithm. Each transaction gets its own instance of the data item, such as in a cache or in an entity bean, such that it is not necessary to lock the data. The instances can come from the data or from other instances. When a transaction updates the data item, the optimistic concurrency algorithm ensures that the other instances are notified that the data item has been changed and that it is necessary to read a new instance, from the database or from an updated instance. 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: Concurrency can be maintained in cluster caching when processing an update request on network server that is storing a local copy of a data item. The request can be processed using the local copy of the data item. A predicated update request can be sent to a network database storing the data item, wherein the database can commit the update if the local copy is current with the data item. If the local copy is not current, the network server can request a new copy, process the request using the current copy, and try another predicated request. The process can continue until the update is committed to the database or aborted. Once committed, any other servers in the cluster can be notified that the data item has been updated. Those other servers can drop any local copy of the data item and can request an updated copy of the data item.

Abstract: Transactions are granted concurrent access to a data item through the use of an optimistic concurrency algorithm. Each transaction gets its own instance of the data item, such as in a cache or in an entity bean, such that it is not necessary to lock the data. The instances can come from the data or from other instances. When a transaction updates the data item, the optimistic concurrency algorithm ensures that the other instances are notified that the data item has been changed and that it is necessary to read a new instance, from the database or from an updated instance. 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 accessing requested data in a database using result set objects. The invention also provides a set of enhancements to the EJB Query Language (“EJB QL”) for providing result sets using EJB QL and to efficiently access databases using select methods within Enterprise Java Beans. EJBQL language extensions allow for the selection and retrieval of result sets. Since the use of the invention is expressed in terms of object relational constructs defined in an EJB deployment, it allows for the retrieval of data from a database expressed in terms of the relationships defined in that EJB deployment.

Abstract: The caching of heterogeneous bean sets has been improved from requiring each bean to have its own cache instance to caching the beans in a single cache. The beans can be identified by generating a unique identifier that is a combination of the bean's primary key and a self-reference identifier of the bean manager associated with that bean. The average size of a bean set associated with a bean manager can be specified such that the cache allocates memory for that set based on the average size. A callback interface can also be used to shift knowledge of a bean life cycle back to the bean manager. 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: The caching of heterogeneous bean sets has been improved from requiring each bean to have its own cache instance to caching the beans in a single cache. The beans can be identified by generating a unique identifier that is a combination of the bean's primary key and a self-reference identifier of the bean manager associated with that bean. The average size of a bean set associated with a bean manager can be specified such that the cache allocates memory for that set based on the average size. A callback interface can also be used to shift knowledge of a bean life cycle back to the bean manager. 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: 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: The feature of automatic retry of container-managed transactions configures the container to allow automatic retries of container-managed transactions that have been rolled back due to exceptions thrown at runtime. More specifically, on a per method basis, the container can be instructed to retry a failed transaction as using a new one up to a specified number of times if that method was the originator of the transaction that has been rolled back. The enabling of automatic transaction retries is accomplished either at deployment time by setting properties in the deployment descriptor of an instance of a class, such as EJB, or at runtime by setting properties on the EJB via a console on the application server. The automatic retry of container-managed transactions is a convenient feature that may alleviate the client of the task of explicitly coding transaction retries. In addition to programming convenience, retrying transactions using this feature may also offer performance benefits.

Abstract: A new feature lets EJB developers implement an EJB Finder in an EJB using SQL in addition to EJB-QL to query an underlying database and map the matched data instances to instances of the EJB. This will enable developers to use the full querying power of their chosen DBMS and will remove the requirement that they learn a new query language. The EJB Finder can be invoked by Java® code, and its features can be specified by the EJB's deployment descriptor(s) in XML format and/or Java® annotations. The SQL queries can be executed against multiple types of databases. Since EJB-QL is a popular high-level object query language that many developers will continue to use, they may continue to use EJB-QL for the majority of their EJB queries. They may drop into SQL when they need to, or use SQL if they simply refuse to learn EJB-QL. This description is not intended to be a complete description of, or limit the scope of, the invention.

Abstract: The present invention provides users and processes with various features to control the memory usage by a cache and pool dynamically at runtime. The cache and pool can be initialized on demand to remove idle objects of classes from them without the server being restarted. When the cache and pool reach their maximum sizes, idle objects in them may be removed to make room for newly active objects using various strategies in batches, where the schedule (periodicity), size and processing time of each batch can be dynamically adjusted. When a newly created object is being added to a full cache where each object is enrolled in a transaction, one or more active objects may be passivated from the cache based on various criteria to make room for the new instance to be added. Various features of the cache and pool can be defined in a configuration file. This description is not intended to be a complete description of, or limit the scope of, the invention.

Abstract: The present invention provides users and processes with various features to control the memory usage by a cache and pool dynamically at runtime. The cache and pool can be initialized on demand to remove idle objects of classes from them without the server being restarted. When the cache and pool reach their maximum sizes, idle objects in them may be removed to make room for newly active objects using various strategies in batches, where the schedule (periodicity), size and processing time of each batch can be dynamically adjusted. When a newly created object is being added to a full cache where each object is enrolled in a transaction, one or more active objects may be passivated from the cache based on various criteria to make room for the new instance to be added. Various features of the cache and pool can be defined in a configuration file. This description is not intended to be a complete description of, or limit the scope of, the invention.

Abstract: The present invention improves the performance of storing multiple instances of a CMP bean enrolled in a transaction by utilizing CMP batch operations to update multiple entries in a database table in one SQL statement only, thus avoiding multiple database roundtrips. The batch operation of CMP beans can be enabled by specifying certain options in a DTD file. As part of the batch operation feature, another option may be added to the DTD file as well, enabling the container to delay all database operations in a transaction until the commit time, automatically sort the database dependency between the operations, and send these operations to the database in a way to avoid any potential database constraint violations. 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 claim.

Abstract: The present invention provides users and processes with various features to control the memory usage by a cache and pool dynamically at runtime. The cache and pool can be initialized on demand to remove idle objects of classes from them without the server being restarted. When the cache and pool reach their maximum sizes, idle objects in them may be removed to make room for newly active objects using various strategies in batches, where the schedule (periodicity), size and processing time of each batch can be dynamically adjusted. When a newly created object is being added to a full cache where each object is enrolled in a transaction, one or more active objects may be passivated from the cache based on various criteria to make room for the new instance to be added. Various features of the cache and pool can be defined in a configuration file. This description is not intended to be a complete description of, or limit the scope of, the invention.

Abstract: Query caching enables the caching of EJB instances at the granularity of query level. It removes the current limitation on EJB caching by allowing the result from an arbitrary query which uses, e.g., either a primary key or a non-primary key, to be stored in the in-memory cache in the container. The query languages utilized by the query can be, but are not limited to SQL and EJB-QL. The performance of an application server can be improved significantly since the result of an query called after the result an identical query has been cached earlier can be retrieved from the cache directly without accessing the underlying database again. In addition, such query caching has an advantage in performance since it can be executed implicitly by the container instead of being explicitly invoked in the application code by the user. This description is not intended to be a complete description of, or limit the scope of, the invention.

Abstract: The present invention uses annotations and SQL to retrieve and/or persist POJO data from/to a database, respectively. Using SQL will enable developers to unleash the full querying power of their chosen Database Management Systems (DBMS) and will remove the requirement that they learn a new query language. A minimal amount of annotations will be associated in the same Java® source file where each class of POJO to be persisted to the database is defined. An enhanced compiler is capable of analyzing the annotated source file and automatically generate the bytecode required to create, deploy, and manage the persistence of POJOs without requiring knowledge of specific details of the persistence to corresponding data entities in the underlining database. Therefore, such an approach decreases the time, knowledge, skill and ultimately cost required to persist POJOs to an underlying database. This description is not intended to be a complete description of, or limit the scope of, the invention.

Abstract: The invention provides a set of enhancements to the EJB Query Language (“EJB QL”) for providing ResultSets using EJB QL and to efficiently access databases using ejbSelect methods within Enterprise Java Beans. Particularly, these EJBQL language extensions allow for the selection and retrieval of ResultSets. Since the use of the invention is expressed in terms of object relational constructs defined in an EJB deployment, it allows for the efficient retrieval of data from a Database expressed in terms of the relationships defined in that EJB deployment.

Abstract: Servers in a network cluster can each store a copy of a data item in local cache, providing read access to these copies through read-only entity beans. The original data item in the database can be updated through a read/write entity bean one of the cluster servers. That cluster server has access to an invalidation target, which contains identification information relating to copies of the data item stored on servers in the cluster. Once the read/write bean updates the data item in the database, an invalidate request can be sent or multicast to all cluster members, or to any read-only bean or server contained in the invalidation target. Each server or read-only bean receiving the request knows to drop any copy of the data item in local cache, and can request a current copy of the data item from the database.

Abstract: Servers in a network cluster can each store a copy of a data item in local cache, providing read access to these copies through read-only entity beans. The original data item in the database can be updated through a read/write entity bean one of the cluster servers. That cluster server has access to an invalidation target, which contains identification information relating to copies of the data item stored on servers in the cluster. Once the read/write bean updates the data item in the database, an invalidate request can be sent or multicast to all cluster members, or to any read-only bean or server contained in the invalidation target. Each server or read-only bean receiving the request knows to drop any copy of the data item in local cache, and can request a current copy of the data item from the database.