ABSTRACT
While CORBA standard implementations and Object Databases (ODB) coexist on the market and are successfully used in different domains as autonomous tools, their integration is often called "synergy" because it offers great benefits for the both sides. The efficiency, flexibility and scalability of particular CORBA/ODB system depends on the properties of the mediating tier residing between two systems, through which the integration is done. Since the performance of CORBA/ODB system is heavily influenced by transactions overhead, the issue of transaction management has a crucial role in CORBA/ODB system's performance improvement. In this article some techniques aimed to minimizing the negative impact of transactions overhead on CORBA/ODB integrated system's performance are described and evaluated.
Keywords: CORBA, Object Databases, transaction management.

1. Introduction
The Common Object Request Broker Architecture (CORBA) [12] standard and Object Databases (ODB) ([3], [9]) are two technologies emerged as a result of rapid expansion of OO paradigm in all sectors of software industry. CORBA revolutionizes distributed processing environment by specifying object-based infrastructure - Object Request Broker (ORB) - providing interoperability between applications written in different languages and running on different platforms, thus seamlessly interconnecting multiple object systems in heterogeneous environment. In turn, ODBs introduce objects to the realm of database systems by extending object-oriented programming languages with database capabilities.

From the very beginning of the existence of both technologies the tendencies towards their integration were observable (e.g. [14]). Since both technologies are relatively young, they still have some deficiencies preventing many software designers from using CORBA in mission-critical applications as well as leading to inability of ODBs to finally conquer relational predecessors. The integration of the two technologies - i.e. the coupling of tools of both technologies to work together in one system - can offer great benefits for the both sides. Through the integration with ODBs modern CORBA tools can be provided database-specific features like persistence, concurrency control, data recoverability, transactions, etc. In turn, the integration with CORBA environment allows ODBs to essentially enhance the potential set of database clients by providing extended heterogeneity, better distribution, better authorization mechanisms, partial implementation of database views, etc. ([2], [13]).

Still, whether the integrated CORBA/ODB systems will be widely used in mission-critical applications heavily depends on their efficiency and scalability. It is extremely important to find the optimal solution for CORBA and ODB interoperation, i.e. to balance the operation of both tools in order to prevent one tool to bottleneck the another. In this domain much remains to be done.

In the subsequent Section CORBA/ODB integration techniques and tools are presented, and the elements crucial for the integrated system's performance are particularized. Next, in Section 3 the importance of transaction management for CORBA/ODB integration performance is discussed. Section 4 introduces three novel extensions aimed to improve the functionality of standard transaction management used for integrated CORBA/ODB systems. The proposed extensions are evaluated in Section 5. The paper is ended with conclusions.

2. CORBA/ODB integration techniques and tools
During the past few years both CORBA and ODB communities tried to define the standard ways of two technologies' integration. The Object Database Management Group (ODMG) - a consortium associating all major vendors of ODB systems tried to define a standard allowing ODB source code portability as well as outlined the principles of the standard-compliant ODBs interoperation through the ORB [3]. The Object Management Group (OMG) promoting the CORBA standard, too, made vigorous efforts to standardize domain-independent means to provide ODBs capabilities to distributed objects connected via ORB ([11], replaced now by [4]). Despite those considerable undertakings no viable standard of CORBA and ODBs interoperation has been specified. Instead, the ODMG and OMG only put forward, without providing any further details, some recommendations concerning a special-purpose Object Database Adapter (ODA) residing between CORBA and ODB tools and coordinating their operation.

The lack of a well-specified standard has resulted in disorganized efforts of CORBA and ODB vendors to provide proprietary tools supporting the CORBA/ODB integration. Some CORBA vendors have released proprietary ODAs oriented towards CORBA applications being integrated with databases ([7], [8]). As a rule those products offer limited flexibility and have rather poor performance. To overcome those limitations some users are forced to implement in-house software layer wrapping specific database to make it accessible via ORB. Although such strategy offers much more flexibility and is applicable to integration of preexisting database applications with CORBA environment, it is non-standard compliant, and its realization requires much programmatic efforts, is time consuming and error-prone¹. Also, as an intermediate solution, a special tool - Orbix Database Adapter Framework (ODAF, [5]) - providing common framework for ODAs design, establishing a unified basis for implementation of OMG standard compliant ODAs specific for particular database, was introduced to the market by Iona Technologies (http://www.iona.com/).

Thus, different approaches adopted on different levels of abstraction can be applied to attain the CORBA/ODB integration. All those approaches have a common component: they imply existence of an additional mediating tier operating between both parties of the integration. The resulting CORBA/ODB system is composed from three tiers, where CORBA operates as a front-end and database operates as a back-end (Figure 1). The CORBA clients are seen by ODB system via CORBA server, which operates as a regular database client.

The general functional architecture of an integrated CORBA/ODB system can be briefly illustrated in the following way (Figure 2).

Regardless of what particular strategy is applied to integrate CORBA and ODB, there are certain common key issues crucial for CORBA/ODB system's functioning [1]. Thus, the basic responsibilities of the mediating tier can be roughly divided upon four main tasks:

• object reference generation and management - references to persistent objects should be maintained in order to ensure the identification and retrieval of the demanded object from the persistent store;
• object activation - the situation when persistent object must be loaded from the disk to the server address space should be recognized and appropriate object activation routine should be called;
• object deactivation - when objects previously loaded from the persistent memory are not longer needed, they should be removed from the server’s address space to avoid its memory overloading;
• transaction management - since every access to persistent objects should normally be done within transaction, a transaction must be open when a persistent data is accessed. More precisely, when persistent object method invocation arrives to server, a transaction has to be open before the object method is invoked² and subsequently committed after the results of method invocation are passed to the client³.

3. Importance of transaction management for the performance of CORBA/ODB systems
The CORBA/ODB system's performance can be significantly worse than the performance of regular CORBA applications that do not store server objects in database. The study conducted in [15] showed that the difference between performances of CORBA and CORBA/ODB systems could reach an order of magnitude⁴. The main factor reducing the CORBA/ODB integrated system's performance is the necessity of enclosing the CORBA server-side operations invocation within transaction boundaries.

In commercial ODAs as well as by ODAF default assumptions two styles of transaction management are generally available. The first one - called per-operation style - causes transaction to be open/commit before/after each operation invocation. The second one - called phased style - lets CORBA clients to explicitly settle transaction boundaries by invoking special operations defined in target object's interface. The principal difference between the two techniques is that transaction boundaries enclose only one operation invocation of target persistent object in the first case, and a bunch of operation invocations in the second one. From the client's viewpoint, the transaction management is done implicitly in the first case, and explicitly in the second one (i.e. clients explicitly manage transaction borders). It should be noted, however, that the per-operation style is much more adapted to CORBA philosophy since the remote (sometimes untrustworthy) clients cannot handle the server's memory, whereas in phased style an evil client can effectively lock the server by delaying an open transaction's committing. Moreover, even if the clients behave properly, the degree of concurrency is much lower in phased style, which negatively impacts the overall performance of the system.

Additionally, when phased style is used, separate server processes for each CORBA client must be activated⁵. Thus, the phased style also threatens server memory overloading if many clients try to access the persistent objects simultaneously.

In fact, it could be stated that the main reasons of introducing the phased style (and consequently compromising the important features of security, concurrency and server memory's protection) are:

• its better performance (in some circumstances)
• possibility to give clients a lever to explicitly handle transactions' boundaries/styles (can be crucial in some applications).

As a consequence, transaction management should be carefully designed in order to reduce the negative impact of transactions handling and to boost the CORBA/ODB system's performance. We focused our attention on various ways of identifying the places where the need of transaction can be eliminated, or where transactions' costs can be minimized.

4. Extensions of transaction management techniques
The standard transaction management applied in commercial CORBA/ODB integration tools proved to have poor sophistication and flexibility. In this Section some useful extensions aimed to improve the limited functionality of standard transaction management are proposed and described. These extensions are built around three different filtration schema - based on detection of: (i) persistence of target objects, (ii) transaction type, and (iii) whether the request is made by the same CORBA client. The term 'filtration' means that the given transaction extension checks the target object, operation or client features to use this information in efficient request processing.

4.1. Persistent objects filtration
In most commercial ready-made ODAs (as well as in accordance with ODAF default methodology) every method invocation on CORBA server, which is linked with database through adapter, causes transaction start, even if the destination object is not persistent neither deals with any other persistent object. In the environment where some considerable part of CORBA server objects are not persistent this can have substantial performance overhead as well as worsen concurrent access of multiple clients.

To minimize transactions' involvement, the first idea was to make adapter to automatically decide whether to open a transaction. Such decision was to be based on the distinction between persistent and transient target objects. This approach, however, is misleading since the object being itself transient can deal with another objects which in turn are persistent (e.g. lookUpObject method of transient object, which can be used to locate other persistent objects). In fact, the decision whether a transaction must be started is difficult to make without having an application-specific information. Instead, some simple and effective means should be provided to application programmer (the adapter user) to instruct the adapter whether it should begin transaction for any particular request of method invocation. For that reasons mechanisms for dynamically passing the adapter an appropriate user-defined function have been added to proprietary adapter. Such function takes the incoming request's parameters (e.g. CORBA's Request object) as an argument and returns boolean indicating whether the destination object needs transaction opening. Additionally, a private flag was introduced to adapter, which indicates whether adapter should use that persistence checking function or not. Thus, the persistence check capability can be switched on/off at any moment. It is the responsibility of an application programmer to implement such function. In the simplest case it would be enough to perform string comparison to decide whether the current request needs transaction (e.g. if the request is standard _IT_PING to transient locator object, the function returns 0). The adapter can also provide default persistence-checking function, which simply returns 1, i.e. in accordance with the default behavior of the adapter every incoming request causes transaction opening.

4.2. Update transaction filtration

Due to approach adopted by ODAF the read-only and update transactions are not differentiated. Thus every transaction started by adapter is supposed to be update transaction. Such inflexibility may negatively influence the performance and concurrency of the application in an environment where considerable part of method invocations is read-only. As most of DBMS products support at least two kinds of transactions - read-only and update, it was decided to introduce the same diversification to the proprietary adapter. For that purpose some additional elements were introduced to the adapter. In particular, a special enumerated type indicating the type of transaction was introduced. The adapter is passed the transaction type information, based on which it determines the kind of transaction (if any) to be open.

At the same time adapter cannot automatically take the decision concerning the type of transaction to be open for particular method's invocation. Indeed, whether a method needs update or read-only transaction cannot be deduced from its interface. Instead, that decision should be delegated to the application programmer (adapter user). As a result, the same strategy as in persistence checking was adopted. The application programmer can pass the adapter an appropriate function, which decides whether a read-only or update transaction should be started. The function's signature is identical to the one described in previous section. Such function's implementation is up to the application programmer and can, for example, contain simple string comparison (e.g. if the requested operation name begins with "_get", then it is read-only operation). Again, as in previous case, a flag indicating whether adapter should use that function can be introduced. The adapter also can provide default transaction type management function. The default behavior of the adapter is that every incoming request causes update transaction opening.

The proposed innovations related with persistence and transaction type management checking (see Figure 3) are illustrated below.

Note, that per-operation transaction style is implied in the presented above considerations. Indeed, when phased style is set, responsibilities of transactions management are delegated to CORBA clients who explicitly handle transaction boundaries. Within those boundaries access to objects of different types can be done. Consequently, the above-mentioned techniques are meaningless for phased transaction style and were introduced to improve performance of per-operation transaction style only.

4.3. Preemptive Transaction Style
To further enhance the efficiency of transaction management the adapter can also benefit the ability of detecting the CORBA client on which behalf the current operation call is being made. In fact, filtering out and group the calls made by the same CORBA client would effectively eliminate the need of opening/closing transactions for each call separately. The detailed description of this strategy, which has been developed and incorporated into the proprietary adapter as an additional transaction style, is given below.

As it was described earlier, ODAF defines two styles of transactions, per-operation and phased. Each has its strong as well as weak points. The per-operation style can incur considerable overhead when many methods of relatively low cost exist in server objects. The phased style violates CORBA principles of separating remote clients from server's memory management as well as makes clients to be aware of persistence of the server-side objects. Besides the overhead of distinct CORBA server process creation for every CORBA client (required in phased style) grows significantly when the number of clients is high, negatively affecting scalability of system. Hence very often neither solution is satisfactory. Transaction-per-request is too costly, yet clients not always should be aware of destination objects persistence, nor manage the server’s memory. It would be beneficial to somehow combine the advantages of both styles (per-operation’s "clarity" and phased’s performance).

Such a style can utilize the fact, that a single-threaded CORBA server after receiving request from a client usually do not accept another incoming operation request until it has completed the current one. The requests (as well as other CORBA events) are queued. A similar behavior has database server, which serializes subsequent transactions by not beginning the next one until the current is not committed or aborted. As a result it is possible to keep transaction open while the subsequent requests are coming from the same client.

At the moment when another client makes a call, the already open transaction must be closed (thus committing changes into database) and a new transaction is open. An adapter should be able to distinguish the clients sending succeeding requests. The overall mechanism works in the following way (see Figure 4)

1. The very first invocation (i.e. no transaction is open) set a special variable within adapter to the current client’s id. For that purpose the best candidate is a file descriptor assigned to the current connection, which is unique while client is connected with the server. After the call is completed, adapter doesn’t commit the transaction ([1] in Figure 4).
2. The adapter checks the subsequent requests’ client ids, if the new request id is equal to the one kept in adapter, none transaction handling is done ([2] on Figure 4).
3. If the client id is different, adapter closes the current transaction (if any is open) and opens new one. The variable is set to the new client’s id ([3] on Figure 4).
4. Adapter utilizes ORB::registerIOCallback⁶ function, which is helpful in cases when particular client disconnects from the server. Adapter checks if the current transaction is open for that client and, if yes⁷, close the transaction simultaneously setting the correspondent variable to 0 (which means that no transaction is open) ([9] on Figure 4). That prevents different clients using the same connection id use the same transaction.
5. When server exits, adapter’s destructor checks whether there is an open transaction and, if yes, commit it.

The two techniques described in previous subsections could be applied in preemptive style. For example, ODA could be instructed to open read-only transaction and, when consecutive request needed update transaction opening, it could be instructed to close read-only transaction and open update transaction. Still, such schema hasn't been implemented in current version of adapter to keep new preemptive style transparent and straightforward. Besides, the effectiveness of described pattern would depend heavily on the type of particular CORBA application - in some cases it would be more beneficial to drop persistence checking and transaction type setting mechanisms to avoid overhead of related functions' invocations.

Yet another improvement of preemptive style was considered. Adapter would have checked if among the pending events were requests from the current client and, if yes, would perform them first, thus grouping requests by their client ids and avoiding the overhead of transaction starting/committing. But such a strategy could cause some clients discrimination, adopting the principle "the first is the best". We decided to treat all clients equally.

5. Evaluation of proposed techniques
To study the role of transaction management in CORBA/ODB system's performance as well as to apply new transaction management technique extensions and to test their viability, different applications based on Iona's Orbix [6] and ObjectStore [10] integrated via proprietary ODAF-based ODA were tested⁸. As an additional point of reference to our proprietary ODA the commercial ODA integrating Orbix and ObjectStore - Orbix+ObjectStore Adapter (OOSA) [7] was used. In ready products like OOSA, the transaction management is too crude and does not offer much space to maneuver for application programmers. We used the ODAF's design flexibility to provide more sophisticated transaction management mechanisms. For the sake of brevity we will further refer to the code residing between CORBA and ODB as adapter (or ODA). It should be emphasized, however, that ODA could be replaced by any other routines performing the above-mentioned mediating tier's basic tasks.

The experiments showed that persistent objects and transaction type filtration techniques’ efficiency is heavily dependent on the specific attributes of a particular CORBA/ODB application – such as the environment in which the application operates, the number of clients concurrently accessing the target objects, the types of operations and so on. Thus, if a significant part of target objects is transient (i.e. they are created from scratch every time CORBA server restarts), the use of persistent object filtration mechanism is fully justified. Similarly, if substantial part of target objects’ operations are read-only, and pure database clients access concurrently the same data, the transaction type management should be used in order to improve the concurrency between CORBA and pure database clients. However, those mechanisms should be switched off if the vast majority of target objects is persistent and/or the bulk of operations needs update transactions. Such environment does not justify the additional overhead the mechanisms cause. In general, the choice whether to use those mechanisms must be made by the programmer for every specific application.

By contrast with the two previous techniques, the preemptive transaction style has proved its superiority over "standard" per-operation and phased styles in the most cases. It has conceptual prevalence over the phased style, since it separates the CORBA clients from server’s memory management, which can be crucial in most CORBA/ODB applications. Additionally, it frees CORBA server from launching a separate process for each CORBA client. Still, in some cases programmers may decide to use phased transaction style if it fits better to the specific application’s logic (e.g. if CORBA clients must be aware of the target objects’ persistency). In turn, being conceptually equal to the per-operation style (i.e. clients are cut off the server’s memory management) the preemptive style has absolute prevalence over it in performance. As it was mentioned earlier, in the worst case the preemptive style’s performance is equal to the per-operation’s performance (i.e. when the consecutive requests are made by different clients). In the best case (i.e. when the consecutive requests are made by the same client), the performance of the preemptive style is equal to the phased style’s performance.

To better measure the mechanisms existing in the integrated application, we decomposed the whole procedure of CORBA client request processing. The following steps were identified: (1) client call through the IDL stub, (2) arguments' marshaling, (3) request sending, (4) request receipt, (5) arguments' unmarshaling, (6) up-call to the destination object implementation through the IDL skeleton, (7) results' marshaling, (8) sending reply, (9) reply receipt by the client, (10) results' unmarshaling, (11) return to the client. When request and reply handlers are applied (e.g. Orbix’s filters), additional steps take place. Thus, in ODAF-made ODA some extra steps are performed on the server side: (4a) request pre-marshal, (5a) request post-marshal, (6a) reply pre-marshal, and (7a) reply post-marshal actions.

To examine the issues of the integrated system's performance and its dependency from the transaction management, it is suitable to separate steps (4a-7a) from the rest. To further simplify the representation we decided to join the steps 4a, 5, and 5a in a phase called preprocessing, and steps 6a, 7, and 7a in phase called postprocessing. Taking time measurements of methods invocations simultaneously on the client side and on the server side, we can evaluate server-side performance separated from the costs related with client-server communication as well as client-side data processing. To illustrate that schema the steps performed on the server side are shown on Figure 5.

Mainly two types of operations on target object were invoked - read-only and update. The measurements were taken for both transaction styles offered in ODAF - phased and per-operation - as well as newly introduced preemptive style. The preemptive style behaves exactly like phased style as far as the consecutive requests come from the same client.

The tests were performed on a Sun SPARCstation 514 running Solaris2.5, using ObjectStore4.0, Orbix2.1c ST, and OOSA2.01. The clients and the sever resided on the same machine. The times measured in seconds on the CORBA clients’ side is presented on Figure 6 (read-only operations) and Figure 7 (update operations). For the sake of simplicity in case of preemptive transaction style with requests coming from different clients it is implied that the operations’ modes are the same for consecutive requests (i.e. read-only operation is preceded by read-only operation). Otherwise, we would have to further divide it upon read-only operation request coming after update operation, read-only operation request coming after read-only operation and so on.

As it is seen, the preemptive style really has advantages of both standard styles and, thus, can be used whenever maximal performance coupled with separation of CORBA clients from explicit transaction management is needed. It should be noted that the cost of the operations' invocation as well as the CORBA communication overhead remains the same for all transaction styles. More importantly, the costs of transactions' opening/committing (pre- and post-processing) remains constant for all applications using the particular style.
 

6. Conclusions
In order to make CORBA/ODB integration more efficient and viable, the mediating tier residing between two systems, besides standard tasks, must fulfill some additional sophisticated functions. One of the most critical domains of mediating tier's responsibilities is transaction management. Several techniques aimed to minimizing the negative impact of transactions' management on CORBA/ODB integrated system's performance have been described. Those include persistent objects and transaction filtration as well as introduction of principally new transaction management style - preemptive style - which concentrate advantages of standard styles, offered by commercial ODAs and is based on subsequent client IDs filtration. The techniques have been incorporated in proprietary adapter based on ODAF, which was used to test their viability. Some possible improvements of presented ideas were also mentioned.

The presented techniques can substantially improve the CORBA/ODB system’s performance. At the same time, however, the persistent objects and transaction filtration should not be used in every CORBA/ODB application. Instead, they can be used selectively in those environments/applications when the overhead they introduce is fully compensated by the benefits they bring. In turn, the proposed preemptive transaction style can fully replace the standard per-operation style as well as make in many cases use of phased style unnecessary. It offers flexible and adaptive behavior performing the costly transactions handling only when needed by grouping the requests coming from the same CORBA client into single transaction borders.

At the same time, it should be noted that the main idea used to identify the situations when the cost of transaction processing can be reduced is also applicable to every other domain where concurrent and transparent access of distributed clients to shared resources takes place. Indeed, the filtration is done on the higher level than (and before) the regular transaction processing is done, thus being independent from the technology used to support ACID⁹ transactions (in our case it was provided by ODB system).

Further developments of CORBA/ODB integration process will be certainly influenced by the need of improvement of integrated system's efficiency and scalability. Transaction management will remain one of the most important areas where more and more refined techniques will be applied to boost the performance of CORBA/ODB systems.

7. References

1. Amirbekyan V., Integration of Object Databases with CORBA Environment, Ph.D. Thesis, University of Mining and Metallurgy in Krakow, POLAND, October 1998;
2. Baker S., ORBs and Databases: Do you need both?, Object Currents, SIGS Publications, Inc., Vol.1, Issue 5, May 1996;
3. Catell R.G.G., Barry Douglas K., et al., Object Database Standard: ODMG 2.0, Morgan Kaufman Publishers, 1997;
4. FUJITSU, INPRISE, IONA, Objectivity, Oracle, Persistence, Secant, Sun; Persistent Store Service 2.0, Joint RFP Submission, orbos/98-05-10, May 1998;
5. IONA Technologies, Orbix Database Adapter Framework, Release 1.0, Iona Technologies Ltd., Dublin, Ireland, June 1997;
6. IONA Technologies, Orbix Programmer's Guide, Release 2.1, Iona Technologies Ltd., Dublin, Ireland, October 1996;
7. IONA Technologies, Orbix+ObjectStore Adapter Programming Guide, IONA Technologies Ltd., Dublin, Ireland, April 1997;
8. IONA Technologies, Orbix+Versant Adapter, IONA Technologies Ltd., Dublin, Ireland, 1997;
9. Manola F., An Evaluation of Object-Oriented DBMS Developments, 1994 Edition, Technical Report TR-0263-08-94-165, GTE Laboratories Inc., Waltham, MA, 1994;
10. Object Design, Inc., ObjectStore C++ API User Guide, Release 4.0.1, Object Design, Inc., May 1996;
11. Object Management Group, Persistent Object Service, October 1994;
12. Object Management Group, The Common Object Request Broker: Architecture and Specification, Revision 2.0, Object Management Group, Inc., Framingham, MA, 1995;
13. Reverbel F., Persistence in Distributed Object Systems: ORB/ODBMS Integration, Ph.D. Dissertation to the Computer Science Department of the University of New Mexico, April 1996;
14. Vasudevan V., Anthony R., Approaches for the Integration of CORBA with OODBs, August 1994;
15. Zielinski K., Amirbekyan V., What CORBA/ODB integration technique to choose: Adapter vs. Wrapper, Workshop #21: Experiences Using Object Data Management in the Real-World, OOPSLA’97 Atlanta, Georgia USA 5-9 October 1997;

1. For detailed analysis and comparison of the both strategies see [15].
2. I.e. before the request arguments are unmarshaled.
3. I.e. after the results are marshaled into the reply buffer.
4. Naturally, the exact extent strongly depends on the specific environment in which the application operates.
5. In fact, most C++-based ODBs (e.g. ObjectStore) support one transaction per client process (i.e. their locking mechanism works on a per-process basis), and from the perspective of database system CORBA server is a regular database client. Hence different CORBA clients should be represented by different CORBA server-side processes to not to bypass ODB's concurrency control mechanisms. Indeed, if one CORBA process is activated and shared by different clients, the database server will fail to distinguish separate clients' requests treating them as coming from one database client.
6. Through this Orbix-specific function users can define functions to be called by Orbix runtime either when a new connection is established between server and client, or when an existing connection is closed (i.e. the connection breaks).
7. If not, adapter does nothing ([4] in Figure 4).
8. One such test application is described in more details in [15]
9. Atomic, Consistent, Isolated and Durable