Abstract: A development-oriented directory structure that can be used with an application server and which solves a number of the problems associated with traditional EnterpriseArchive (EAR) files, comprising: a source folder that stores source files for use with or as part of a software application; an output folder that stores compiled files for use with or as part of said software application; and, wherein said source folder and said output folder output folder form a split directory for use in deploying said software application.

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: 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.

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.

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: In an account transaction such as an ATM transaction, a server in communication with an ATM stores a copy of the account balance. Before processing the transaction, the server reads the balance from memory and determines whether the account contains sufficient funds for the transaction. In order to prevent overdrawing of the account, the server makes any balance update predicated on the fact that the current balance in the account database is the same as the balance of the local copy of the account. If the account balance stored in the database is not the same, the server rolls back the request and updates the account balance stored in the local copy. This process continues until either the account balance is updated or the transaction is aborted.

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.