Browse Prior Art Database

A mechanism and system for continuing process of Enterprise JavaBeans requests independent of database locking issues which may stall the request.

IP.com Disclosure Number: IPCOM000125448D
Original Publication Date: 2005-May-31
Included in the Prior Art Database: 2005-May-31
Document File: 2 page(s) / 50K

Publishing Venue

IBM

Abstract

This invention is a mechanism for optimizing performance of an Enterprise JavaBeans* (EJB) container-managed persistence (CMP) runtime using asynchronous processing of operations that result in database requests. This will yield better performance in the majority of customer applications that have multiple database interactions that occur interlaced with significant business logic execution.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 48% of the total text.

Page 1 of 2

A mechanism and system for continuing process of Enterprise JavaBeans requests independent of database locking issues which may stall the request .

The invention being disclosed would be an addition to an application server runtime that would allow for container-managed persistence (CMP) database queries to be executed in parallel with business logic inside of a single transaction promoting a higher degree of throughput and faster response times. Currently, all application servers when executing a query to load data from a database into a CMP perform that load of data with a single thread of execution, blocking till the database machine returns data. This new invention is a step forward in providing better performance for the CMP runtime and getting more concurrency out of the application server. The relevant documentation on how the current system works can be found by reading the CMP2.X specification as well as the manuals of all the relational database management system (RDBMS) systems on the market.

     Currently the Enterprise JavaBeans* (EJB) container inside of WebSphere** application server (WAS) and other application servers must wait for database requests to return the result set after a query is issued to the database to load a CMP bean before processing can continue. This time can be variable based upon the amount of locking on the table/row that the bean is trying to load, network latency, and even database tuning. This leads to inconsistent response times and, in some cases, response times that do not meet customers criteria for average case scenarios. This invention using a callback mechanism that allows the CMP container to issue queries to the database to load information on a separate thread (running on the database) while the main thread of execution continues processing business logic in the application up until the data from the database query is needed. If the callback from the query returns before the main thread of execution needs the data, it will be available for the main execution thread and processing will continue uninterrupted, if it is not returned in time the main thread will block until the callback from the query is executed from the database.

     The idea being disclosed is for continuous processing of CMP's if a request is issued for data for one bean's data but the database is locked from returning the row because of a currently operating transaction having the lock. When this occurs, an interface used for DB2** to callback on the bean in the EJB container would be registered from DB2 and as soon as the lock is released the database would call this interface loading the data into the bean in the EJB container. At that times, the currently processing transaction would be notified the data was loaded so it can access it. Since most developers typically gather all the data they need for transaction before they actually start performing computations on it, this asynchronous callback mechanism for locked da...