Database persistence with Enterprise JavaBeans

Mikael Eriksson

Database persistence with Enterprise JavaBeans

2000:052

MASTER'S THESIS

Civilingenjörsprogrammet Institutionen för Systemteknik Avdelningen för Programvaruteknik

&RQWHQWV

&217(176 

$%675$&7  

35()$&( 

,1752'8&7,21  

%$&.*5281' 

ENTERPRISE JAVABEANS ARCHITECTURE... 6

THE ENTERPRISE JAVABEAN... 7

CONTAINER-MANAGED PERSISTENCE (CMP)... 8

BEAN-MANAGED PERSISTENCE (BMP) ... 9

'(),1,7,212)675$7(*,(6  STRATEGIES BASED ON CMP ... 10

&03$  &03%  &03&   STRATEGIES BASED ON BMP ... 12

%03$  %03%  %03&  %03'   ,03/(0(17$7,216  TEST CASES... 14

EVALUATION OF STRATEGY COMPLEXITY... 15

&RPSOH[LW\RI&03VWUDWHJLHV  &03$  &03%  &03&   &RPSOH[LW\RI%03VWUDWHJLHV  %03$  %03%  %03&  %03'   7(676   TEST ENVIRONMENT... 19

TEST RESULTS... 19 3HUIRUPDQFHWHVW  

(IILFLHQF\WHVW  

6FDODELOLW\WHVW 

%(1&+0$5.6 

&+226,1*7+(%(67675$7(*< 

5()(5(1&(6  

$33(1',;(6  

APPENDIX 1 ... 29 APPENDIX 2 ... 30 APPENDIX 3 ... 31

$EVWUDFW

The problem of database persistence is well known and well documented.

However, with the introduction of the Enterprise JavaBeans architecture new issues have arisen. Now you have the choice of delegating all the work of persistency to the application server, but what effects will this have on performance and stability? If you choose to manage all persistency on your own, will the extra complexity introduced really be worth it? This is the kind of question this thesis will attempt to answer.

I have defined a variety of different strategies and evaluated them all. This evaluation will attempt to determine all aspects of any given strategy in order to get an overview of the pros and cons of different solutions. It has not been my intention to find WKH solution, since this may vary depending on the requirements. Nevertheless, I hope to make it easier for future developers of systems based on the Enterprise JavaBeans architecture to find the persistence strategy that best matches their requirements.

3UHIDFH

This work was conducted during the spring and summer of 1999 at InterBizz Financial Systems in Stockholm, Sweden [5]. It was one critical aspect of the development of a new Internet-related financial trading system based on the Enterprise JavaBeans architecture (ROX2). I hope that my work will prove useful to the developers of ROX2, and all future related projects thereafter.

I would like to thank all the people at InterBizz Financial Systems for support, professionalism and valuable feedback. And of course my examiner, Johnny Widén at Luleå University of Technology for shown interest and support.

,QWURGXFWLRQ

Enterprise JavaBeans (EJB) is a new and promising architecture for distributed Java application. This thesis will attempt to explore the problem of database persistency within this environment. It focuses on the different choices of persistence for Entity Beans, which are divided into container-managed and bean-managed. In the case of container-managed persistence the container is responsible for generating all database code needed to keep the Entity Beans persistent. This is the simplest way of achieving persistence in EJB, all that has to be done is to tell the EJB container which of the fields in the entity Bean that should be persistent. However, the simplest way of doing something is not likely to be the most efficient one. That is one of the things this thesis will address, the balance between simplicity and performance. Another factor that will be evaluated is flexibility (the ability to adapt to different environments). The last measurement used to evaluate the strategies is scalability, basically how well each strategy can handle an increase in the number of simultaneous clients.

These four measurements (performance, flexibility, complexity and scalability) are defined in Appendix 3.

In order to cover as many different strategies as possible much work has been put into exploring different ways of achieving database persistence. However, to avoid overwhelming the reader these strategies was cut down to one representing each major way of achieving persistence. The goal of this thesis is not to WKH best way of achieving database persistence. The primary result will be a clear overview to make the choice of persistence strategy easier for developers.

The first part of this thesis gives an overview of the EJB architecture and explains how my work fits into the big picture. This is followed by definitions of the strategies that have been evaluated. In conjunction to each strategy, an evaluation of the flexibility can be found. The next section will then describe how the strategies were implemented and the decisions that had to be made there. This section also includes an evaluation of the implementation complexity for each strategy. After the implementations follows definitions and results of the tests that the strategies have gone through. The factors reviewed in this section are performance and scalability. To get an overview of the time constraints involved the following section gives benchmarks for each strategy.

Finishing of this thesis is a section about choosing the nest strategy and my personal conclusions.

%DFNJURXQG

Since Enterprise JavaBeans is a new and hot technology this section will give a little bit of background on Enterprise JavaBeans. This will be focused on describing why EJB was needed, how it works and to give an in-depth description of the persistence mechanism.

(QWHUSULVH-DYD%HDQV$UFKLWHFWXUH

First of all, Enterprise JavaBeans is a specification of behaviours, not a product.

The EJB specification [1] describes how different components should behave and what rules that has to be fulfilled. This gives developers of server-side Java application a standardised architecture and promotes reuse. When developing server-side Java there are a few reoccurring tasks to deal with, e.g. transaction handling, persistence of data, distribution of components and security. EJB was designed to automate these tasks for the developer, giving the developer more time for the business logic. Some of the major goals of EJB were [1]:

• Create a standard architecture for distributed object-oriented business applications.

• Ease application development by not requiring developers to understand low-level complex APIs.

• Support the “write-once, run anywhere” philosophy

An EJB server consists of at least one container, as depicted in figure 1 below.

The container is the place where the beans are deployed and executed, just as a file resides in a file system. It is the container’s responsibility to make the bean’s home interfaces available to the client via Java Naming Directory Interface (JNDI) [3]. This way the client can find the bean and use Remote Method Invocation (RMI) [2] to access them. When a client wants to create an EJB object from a bean it is done by a RMI call that passes through the container.

This gives the container an opportunity to create the EJB object and handle other creation activities before returning a reference to the client.

Figure 1 – The EJB Architecture

7KH(QWHUSULVH-DYD%HDQ

There are two different kinds of beans, the session bean and the entity bean. The session bean is a non-persistent bean that implements some business logic and has the same lifetime as the client that uses it. It is generally responsible of keeping track of the state of an operation or a client. When the client does not need it any more the session bean is destroyed. Because the session bean is non- persistent it will not survive a server crash.

The entity bean is persistent and is used to represent data in the EJB server. It can be used directly from a client or from another bean in the server. Since the entity bean is persistent it will store any changes made in it to some persistent storage, e.g. a database. The persistence mechanism is described more thoroughly in the sections &RQWDLQHUPDQDJHG SHUVLVWHQFH and %HDQPDQDJHG

SHUVLVWHQFH Each bean must have a deployment descriptor that describes how the bean is deployed and how it should be treated by the container. In addition to the deployment descriptor, each bean that should be accessible from a client must have a home interface that exposes the bean methods that the client can use.

Except for the business methods a bean must also implement a number of EJB methods that are used by the container. The names and a short description of these EJB methods are given below in table 1.

(-%PHWKRGQDPH 'HVFULSWLRQ

EjbCreate() Executed upon creation of the bean.

EjbPostCreate() Executed directly after the creation of the bean, gives the developer an opportunity to make the bean ready for use.

EjbDestroy() Destroys the bean.

EjbActivate() Brings the bean in from the bean pool.

EjbPassivate() Places the bean in the bean pool.

EjbLoad() Executed every time the bean needs to update its fields from the database.

EjbStore() Executed as soon as a business method has executed.

After this method all fields must be persistent and consistent with the database.

EjbFind<METHOD>() Locates a specific bean by searching the database using the given information.

7DEOH'HVFULSWLRQRI(-%PHWKRGV

&RQWDLQHUPDQDJHGSHUVLVWHQFH&03

When using CMP the application server generates all the database code. The developer just have to tell the container which fields that should be persistent, then the container will handle all database access. After a completed call to a business method the container will check if the Bean needs to be written. This is normally done using a dirty flag, which if true indicates that the bean should be written to the database. If the container notices that the bean is dirty it will call the ejbStore-method before writing to the database. This gives the developer a chance to update the fields in the bean before it is written. If nothing has to be done to the fields this method can simply be left empty.

Generally CMP gives shorter time to delivery. The most important reason for this is that the developer does not have to write any database code at all.

Database coding tends to be time consuming, because of the large amounts of complex code often needed. Many EJB servers also have support for a database connection pool that will improve performance since creating a database connection takes time. However, CMP has its disadvantages as well. The most crucial one is the limitations imposed by letting the container generate the database code. If the container lacks support for object-oriented databases or relational tables these options will be impossible to utilise.

Container-managed persistence is the simple but limited solution to achieve database persistence for Entity Beans.

%HDQPDQDJHGSHUVLVWHQFH%03

In the case of BMP the container will always call the ejbStore-method after a completed call to a business method and then assume that the bean is persistent.

So when using BMP the ejbStore-method must contain all code for writing the persistent fields to the database. It is completely up to the ejbStore-method to determine whether or not a database access is needed. This will result in more complex code than in the case of CMP, but it gives much more freedom when choosing how to do this. There is one way to keep the bean persistent using BMP without implementing database access in the ejbStore-method. That is when the business-methods themselves write the changes to the database, this way the bean is never dirty. When choosing what type of database to use the container will not impose any limitations at all.

Bean-managed persistence can be thought of as the powerful but lengthy solution to achieving database persistence for Entity Beans.

'HILQLWLRQRIVWUDWHJLHV

The strategies defined here are the ones that have been considered to be the most likely ones to be used. All the strategies use a relational database as secondary storage, but no strategy utilises relational tables. Another requirement imposed on all strategies is that they always have to keep the database updated, an entity bean is not allowed to cache any changes [2].

The different strategies are defined and described below. An evaluation of the flexibility of each strategy has also been done and is summarised in table 2 and 3.

6WUDWHJLHVEDVHGRQ&03

When trying to find update strategies in the case of CMP there are a few restrictions to keep in mind. The deployment descriptor describes which fields should be updated against the database. The container will look at the deployment descriptor and generate the necessary database calls. When the container finds it necessary it will update all fields against the database. This way all data will always be written not just the data that has been changed since the last time. The reason for this is that the container can not know which of the fields has changed and therefore writes all fields. There is not much a developer can do to avoid this when using CMP. However, with this in mind one should be careful not to store too much data in a single entity bean. Consider for example when some sort of logging is done. Instead of having one entity bean containing the entire log a better solution is to have an entity bean for each item in the log.

This way each log item can be represented by one row in the database and updates will be small and efficient. The acronyms for the strategies are defined in Appendix 1.

&03$

The simplest case of CMP is to simply map each field in the entity bean against one column in the database. This is a very simple solution where the container takes care of all database accesses and the developers just have to write the business logic. However, the types of fields that can be used in the entity bean are limited to the ones that the database can handle. This can also have a negative impact of the portability between databases. The field types handled by different databases varies so it is recommended to only use the most common ones in order to avoid data types that might be specific to one database vendor.

&03%

With the Weblogic EJB server [7] used in this thesis there is an additional feature called isModified, something that is not part of the EJB specification.

When using the isModified feature it is possible to mark each entity bean as modified or not modified. This efficiently avoids unnecessary database updates after a call to business methods that do not change any of the persistent fields.

The second CMP strategy is the same as the one mentioned above with the addition of the extra isModified usage. The isModified feature will be used in the rest of the strategies, both BMP and CMP, unless otherwise is clearly stated.

&03&

To be able to handle complex data types one solution is to store all fields in the entity bean as a binary stream. This requires that the database have a data type that can handle binary data, for example BinaryLargeOBject (BLOB). One way to do this is to have a byte-array field in the entity bean. In the deployment descriptor one would specify that the byte-array field should be made persistent against the database. Before the container writes the field to the database the fields in the entity bean must be externalised and stored in the byte array. The container will then write the entire byte-array as binary data to the database.

Later when the byte array is retrieved from the database all the data must be internalised from the byte array.

This strategy has the ability to store any data types that can be externalised, which makes it very flexible. A disadvantage of using BLOBs is that it is impossible to check what is in the database without internalising the entire BLOB. That is, a simple database administration tool can not view data in the database. Externalising all fields in the entity bean and storing them is the third CMP strategy evaluated.

These three strategies mentioned above (CMPA, CMPB and CMPC) are the only container-managed strategies that have been evaluated.

6WUDWHJ\ )OH[LELOLW\

CMPA – Update all always as fields

* Can only handle simple data types

* Can cause lack of portability between databases CMPB – Update all

when modified as fields

* Can only handle simple data types

* Can cause lack of portability between databases CMPC – Update all

when modified as blob

* Can handle all externalisable data types

* Requires binary data type in the database 7DEOH6XPPDU\RIIOH[LELOLW\RI&RQWDLQHUPDQDJHGSHUVLVWHQFHVWUDWHJLHV

6WUDWHJLHVEDVHGRQ%03

%03$

The first bean-managed strategy evaluated is the simple case where each field in the entity bean is mapped against one column in the database without using isModifed. This is the same strategy as the first CMP strategy, with the exception that this one is bean-managed. And as with CMPA this strategy does not utilise the isModified feature and will therefore perform updates towards the database after every call to a business method. Since it is bean-managed the developer has to write all database code to write and read data to/from the database. To keep this strategy simple it will always update all fields whenever it notices that a business method has been executed. This strategy is not very likely to be used in real life since it is better to use CMPA where no database code has to be written. However, it is still interesting to evaluate this strategy to see whether or not writing the database code yourself results in better performance than letting the container do it.

%03%

The second strategy is the same as BMPA with the exception that this one uses isModified.

%03&

To increase the support for complex data types this strategy externalises all the fields in the EJB into a byte-array that is written to the database whenever the EJB is dirty. This will result in a very flexible solution that can handle all data types that are externalisable. See the definition of CMPC for further information about externalisation.

%03'

Yet another solution is to let the business methods make their own updates to the database. This is done by mapping the fields against a row in the database.

Since the business methods do their own updates they know which fields they have changed and will only need to write those. This efficiently minimises the amount of data that needs to be moved to the database and should therefore scale pretty well. As for flexibility this strategy can only manage the same types as the database supports.

Strategy Flexibility BMPA - Update all

always as fields

* Supports the same data types as the database

* Can cause lack of portability between databases BMPB – Update all

when modified as fields

* Supports the same data types as the database

* Can cause lack of portability between databases BMPC – Update all

when modified as blob

* Supports all externalisable data types

* Requires binary data type in the database BMPD – Update

using business methods

* Supports the same data types as the database

* Can cause lack of portability between databases

7DEOH6XPPDU\RIIOH[LELOLW\RI%HDQPDQDJHGSHUVLVWHQFHVWUDWHJLHV

,PSOHPHQWDWLRQV

This section will thoroughly describe how the strategies have been implemented and what decisions that was made during this process. The main reason for implementing the strategies was to be able to test the performance and scalability. In addition, an evaluation of the implementation complexity has also been made and is described below in a separate subsection.

Besides from the strategies, an implementation of a client has also been done.

This client is responsible for making the necessary calls to the ejbMethods on the EJB that is deployed within the EJB server. All of the measurements of time were done from the client. The decision of placing this in the client was to avoid the timing mechanism itself to affect the results. So the times measured includes everything from when the client calls the ejbMethod until it returns. This includes JNDI, round-trip times and activation of beans in the servers. To get more accurate results each client will do its task ten times and report the mean value of this as the result. Since all tests were run in the same environment the results shown below are considered to be accurate when compared to each other.

To be able to run all tests with the same client a few extra features have been implemented in the client. The first of these is the ability to thread itself, this way the client can act as several concurrent clients putting pressure on the server. Each of these clients will do exactly the same thing that will increase the load on the database since all clients want to use the same table. When several concurrent clients were used the mean value of all the results of these was used as result. The next feature is the ability to vary the number of fields to change in the bean. This was implemented in a way so that it can obtain the value of zero, one or all.

7HVWFDVHV

In an attempt to get an environment as real as possible the test case here has been extracted from a real life product, ROX2 [6]. The test case here simulates an order in ROX2. Table 4 below shows exactly the fields that have been used and what their respective types are.

The same client was used in all the tests. It was designed so that it can vary the number of fields to change and the number of concurrent clients.

One EJB was designed for each strategy. In the cases of BMP the EJB opens a connection to the database upon creation and does not close it until it is destroyed. In the case of CMP, the BEA Weblogic server [7] uses a database connection pool that gives connections to the EJB when they are activated.

As described earlier each strategy was implemented using a single bean. This bean consisted of the fields that are shown in table 4. The Class used in the EJB is a serialisable class containing one String and one int. All objects and data stored in the EJB are created by the client and then transferred to the EJB using the ejbCreate-method. The total size of all fields when serialised into a BLOB is 984 bytes and was considered to a good representation of a general EJB.

Strategies that are unable to handle complex data types, like the Hashtable, use the byte-array to serialise all the complex fields. It will however still store as many fields as possible using columns in the database. In general this means that the Strings, booleans and ints are stored in fields and the Hashtables and the Class are stored in the BLOB. This was done to ensure that all the strategies have the same task to accomplish.

4XDQWLW\ 7\SH &RPPHQW

7 String Each string is 20 characters 2 Boolean A one bit value

3 Int An integer value

2 Hashtable Each one containing 10 elements, each a string of 10 characters

2 Class A class containing 1 String and 1 int.

1 Byte[] Used when serialising data to a BLOB

7DEOH'HILQLWLRQVRIWKHSHUVLVWHQWHQWLW\EHDQILHOGVXVHGLQDOOVWUDWHJLHV

(YDOXDWLRQRIVWUDWHJ\FRPSOH[LW\

When choosing a strategy one of the important things to keep in mind is the implementation complexity. This is basically a measurement of how complicated the strategy is to implement properly.

In general container-managed persistence is less complex than bean-managed persistence. The reason for this is that in BMP one must implement all database access, which is not necessary in CMP. Another general difference in the complexity between the strategies is if they use externalisation or not. Whenever externalisation is used it adds a lot of code to the bean.

&RPSOH[LW\RI&03VWUDWHJLHV

If one avoids using externalisation in CMP the persistency code will be kept at a minimum. If one chooses to use the first CMP strategy no persistency code has to be added to the entity bean at all. However, as discussed earlier this will put some limitations on the flexibility, one might not be able to represent all the needed data as simple types that the database can handle. In order to do this in CMP one could use externalisation and store the data as a binary stream. This externalisation can get somewhat complicated to implement and should be avoided if possible. The use of isModifed does not add any huge amounts of code, but one must be very careful when implementing it. Each business method must be evaluated to be sure whether or not the entity bean has to be written after the method is done. Any mistakes here might lead to inconsistency and possibly loss of data that should have been persistent in the database. Summaries of the different strategies’ complexity are shown in tables 5 and 6.

&03$

From a complexity perspective CMPA is a beautiful solution. The only thing that has to be done is to write the business logic and then state in the deployment descriptor which of the fields in the bean that should be persistent. The container will then update these fields towards the database after every completed execution of a business method. There is no need to write any database code and no other code for the persistence mechanism. The implementation of this strategy was the easiest one of all the strategies evaluated here.

&03%

As with CMPA this strategy is easily implemented. The only difference compared to CMPA is the extra usage of the isModified feature. This does not add any complex code to the bean, but one should be cautious to ensure that the bean is marked as modified at the right places. The code added will be an extra isModified method that simply returns the isModified flag (true or false) and the code to change the value of the isModifed flag within the EJB and business methods.

&03&

Since CMPC uses externalisation of the fields in the bean before updates this will add some complexity to the bean code. What needs to be done before allowing the container to write the BLOB is that all persistent fields in the bean needs to be written to a byte-array. This is not immensely complicated but it will add a lot of code in the ejbPreStore and ejbPostLoad. There is also a performance concern here since it for a large bean is quite an amount of code to be executed. CMPC is the most complicated CMP strategy evaluated, but it remains fairly straightforward.

6WUDWHJ\ &RPSOH[LW\

CMPA – Update all always as fields

The simplest strategy available when looking at implementation

CMPB – Update all when modified as fields

Still very simple, but the modified flag must be carefully implemented

CMPC – Update all when modified as blob

Adds a lot of code to externalise the entity bean to the byte-array

7DEOH6XPPDU\RIFRPSOH[LW\RI&RQWDLQHUPDQDJHGSHUVLVWHQFHVWUDWHJLHV

&RPSOH[LW\RI%03VWUDWHJLHV

The advantage of BMP is that the developer gets full control on how the updates towards the database are done. Usually when one moves away from the automated way of doing something things tend to get more complicated. This is also the case in persistence of entity beans. Database coding is rather straightforward but there are a lot of things that must be done and done correctly.

If one chooses to use BMP, the variety of strategies available increases since one can do it pretty much the way one wants to. For the use of isModifed the same rules apply here as in CMP, be very careful and make sure that everything is accurate.

%03$

The complexity in BMPA is the database code for updating the fields towards the database. This is fairly straightforward in BMPA since all fields are updated after every call to a business method. One can simply use a single statement that is used at every update and this makes it fairly simple to implement. Of course the complexity of the bean has a great impact on the complexity of the database code so one should strive towards keeping the beans simple and limited.

%03%

This strategy is equally complex to implement as BMPA with the addition of the extra usage of the isModified feature as described in &03&.

%03&

As mentioned earlier externalisation adds a lot of code to the persistence mechanism. However, in BMP with externalisation the database code will be greatly simplified since it is only one field (the byte-array) that needs to be updated. So the cost of choosing externalisation in BMP is reduced from a complexity perspective.

%03'

By doing the database updates within the business methods each update will need its own statement and this code resides inside the business methods. This is generally not a good solution since one should try to keep the business methods as simple as possible. An alternative to keeping the database code within the business methods is to use an extra store method with arguments indicating which fields that should be updated. This solution would only add a single method call within the business methods and the database code would be separated from the business logic. However, the implementation of this will be much more complex and harder to maintain so this is generally not recommended.

6WUDWHJ\ &RPSOH[LW\

BMPA –Update all always as fields

The simplest BMP strategy. However, updates to the database must be implemented carefully.

BMPB – Update all when modified as fields

Same as above, but with the implementation of the modified flag.

BMPC – Update all when modified as blob

Adds code for externalisation, but makes the database coding much simpler.

BMPD – Update using business methods

This strategy adds database code inside the business methods, which generally is not a preferable solution.

7DEOH6XPPDU\RIFRPSOH[LW\RI%HDQPDQDJHGSHUVLVWHQFHVWUDWHJLHV

7HVWV

Now when all the strategies have been defined and implemented it is about time to look closer at how they perform. This section will describe how the strategies were tested and summarise the results of these. A closer definition of the test environment, test cases and the test results can be found below.

7HVWHQYLURQPHQW

The hardware used when testing the strategies is described in Appendix 2. In that appendix there are also definitions of the database, EJB server and virtual machine used. Since the clients and the server were running on the same host the performance of the network will not have any impact on the results. The machine itself proved to be powerful enough to handle both clients and server without them interfering with each other. As for the database it was emptied before each run in order to give each strategy and each test the same initial conditions. Great care has been taken to ensure that each test and each strategy will have the same preferences when run.

7HVWUHVXOWV

When testing the strategies two abilities have been evaluated: performance and scalability. These tests are described more thoroughly below. Visual representations of the test results are shown in diagram 1, 2 and 3. For each diagram there is also a related section describing the most vital observations.

3HUIRUPDQFHWHVW

The performance was evaluated by using a single client doing a single update against the database. This test will mainly show how fast the particular strategy can complete a database update.

(IILFLHQF\WHVW

The efficiency test uses 10 concurrent clients that change 0, 1 or all fields in the EJB. This gives a hint on how the different strategies can handle different change patterns. How these change patterns looks is impossible to predict and will probably change from product to product. However, one can keep in mind when designing EJB system to try to batch as many changes as possible in to one method invocation. This way time consuming database updates, for example, 5 consecutive invocations of set-methods can be avoided.

6FDODELOLW\WHVW

The scalability test always changes 1 field in the EJB and increases the number of concurrent clients from 1 up to 100. The choice of changing 1 field is because this is likely to be the most common use of an EJB. This test will basically show how well the strategies can handle an increase of concurrent clients. Since all clients within the same test uses the same strategy all clients will try to write to the same table at the same time. This will benefit strategies that can do an update to the database quickly.

'LDJUDP±$VLQJOHFOLHQWH[HFXWLQJDVLQJOHEXVLQHVVPHWKRG

Diagram 1 shows how long time it takes for a single client to do a single business method that changes zero, 1 or all fields in the bean.

When looking at the diagram one quickly sees that there is a major difference between the strategies when zero fields are changed. CMPA and BMPA perform very badly in comparison to the others. The reason for this is that CMPA and BMPA does not have the isModified-feature implemented. So these strategies will access the database even though no fields have changed.

Another important observation is that all the BMP strategies outperform the CMP strategies when more than zero fields are changed. The conclusion of this is that BMP always is faster than CMP when doing updates against the database.

BMPD is the BMP strategy that takes the longest time to complete its task. The reason for this is that it has to prepare a statement with the fields to update. All of the other strategies use already prepared statements.

'LDJUDP±(IILFLHQF\WHVW

The efficiency test uses ten concurrent clients that all executes a single business method that changes zero, one or all fields in the bean. This test will show how the performance changes when there are several clients doing the same thing.

The main difference between this test and the performance test is that this test shows how the different change patterns (zero, one and all) is affected by a higher load.

As in the single write test CMPA and BMPA performs badly when zero fields are changed. Another similarity is that all BMP strategies perform better than the CMP strategies. However, there are differences as well. In diagram 1 BMPD is the BMP strategy that takes the longest time to complete its task. When looking at diagram 2 one can see that BMPD now is one of the fastest. The reason for this is that BMPD’s time in the database is very short and it will therefore quickly release the resources to another client. As described in conjunction to diagram 1, BMPD performs badly there since it has to prepare a statement. This preparation will however not affect the time it takes inside the database.

'LDJUDP±6KRZVKRZWKHVWUDWHJLHVKDQGOHDQLQFUHDVHRIFRQFXUUHQWFOLHQWV

The scalability test uses several concurrent clients that all executes a business method that changes one field in the database. The number of clients used was 1, 5, 10, 50 and 100. Since all clients uses the same kind of bean they will all try to change data in the same table in the database. It was considered unlikely that more than a hundred clients ever would try to access the same table at the same time.

The first thing to notice here is that all the BMP strategies has better scalability than the CMP strategies. This was expected since the BMP strategies have shown good performance in the earlier test and will therefore release their resources earlier, which increases the scalability.

Notable is also that the strategies that uses BLOBs (CMPC and BMPC) scale better than the ones using fields. A possible reason for this is that it a single BLOB is faster to write than writing all the fields to a row.

However, the most outstanding observation in diagram 3 is that BMPD scales significantly better than the other strategies. Updating using the business methods obviously gives both better performance and outstanding scalability.

%HQFKPDUNV

The benchmarks found below is the results of the tests which the diagrams was based on. This gives a hint of which time intervals the different strategies represent. Though these results are based on the test environment, it gives an idea of what performance can be expected from the different strategies.

&KDQJHG

ILHOGV &03$ &03% &03& %03$ %03% %03& %03'

 75 12 13 51 7¹ 7¹ 7¹

 73 74 72 58 43 49 23

$OO 77 76 68 58 52 41 65

7DEOH6LQJOHZULWHWHVW7LPHLQPLOOLVHFRQGV

&KDQJHG

ILHOGV &03$ &03% &03& %03$ %03% %03& %03'

 410 36 63 122 9¹ 8¹ 7¹

 397 423 379 281 194 260 123

$OO 429 428 332 262 186 282 195

7DEOH(IILFLHQF\WHVWFRQFXUUHQW7LPHLQPLOOLVHFRQGV

1URI

FOLHQWV &03$ &03% &03& %03$ %03% %03& %03'

 72 82 63 60 50 40 27

 215 281 213 107 102 72 55

 426 462 364 220 322 261 111

 2652 3271 2619 2176 1672 1520 876

 6591 7445 6428 4997 4292 3925 1881

7DEOH6FDODELOLW\WHVWFKDQJHV7LPHLQPLOOLVHFRQGV

(¹) When zero fields are changed the isModified-feature avoids the unnecessary database access.

&KRRVLQJWKHEHVWVWUDWHJ\

When deciding which of the strategies to implement in an EJB there are several things to consider. The questions that needs to be answered for each of the persistent entity beans in order to find the best possible strategy are listed below:

1. Is performance more important than time-to-market?

2. Will the beans contain complex fields that a database is unable to handle?

3. Is scalability a main issue?

The first choice that has to be made is choosing between BMP and CMP. As shown in the test results BMP has better performance than CMP. So if the answer of question 1 is yes then the obvious choice is BMP. If the answer for is no then CMP will be a better choice and the complex implementation of a BMP strategy is avoided.

As for choosing strategy within BMP and CMP the most vital question is number 2, as stated above. If the beans will contain fields that the database can not handle a strategy that uses BLOBs is recommended. This will ensure that all data within a bean can be represented and stored in any relational database.

However, if the beans only contain simple fields the extra complexity of BLOBs should be avoided and a strategy based on fields should be used. When choosing between the BMPB methods without complex fields one can choose either BMPB or BMPD. The advantage of BMPB is that it keeps the business methods free from database code. However, BMPD gives better scalability and if that is important enough BMPD is the best choice.

Below is a summary, table 10, which based on the answers of the two first questions above gives my personal recommendation of which strategy to use.

4XHVWLRQ 4XHVWLRQ 3UHIHUUHGVWUDWHJ\

Yes Yes BMPC

Yes No BMPB or BMPD*

No Yes CMPC

No No CMPB

7DEOH&KRRVLQJWKHEHVWVWUDWHJ\

(*) The choice between BMPB and BMPD under these circumstances is mainly based on scalability, question three above. BMPD will scale better, as shown in the test results, but will introduce database code within the business methods. If scalability is more important than keeping the business methods clean choose BMPD, if not choose BMPB.

In none of the cases above is BMPA or CMPA a preferred solution. The reason for this is that the extra time spent on implementing the isModified-feature will increase performance to an extent that it would be foolish not to do this.

However, if one chooses a CMP strategy and uses an EJB server that does not support isModified there is not much a developer can do about it. Still if it is a BMP the recommendation of implementing isModified still applies.

When looking at real-life project a common strategy is to start of with CMP for every bean to get the system up and running as fast as possible. Then it is possible to pinpoint the beans that need optimal performance and implement BMP for these beans. This way the extra time it takes to implement BMP is only used where it is needed the most.

&RQFOXVLRQV

The main result of my work is an evaluation of different strategies and basic guidelines of how to choose the best strategy. This can be found under the section ‘&KRRVLQJ WKH EHVW VWUDWHJ\¶. The general advise when choosing persistence mechanism is to start with CMP everywhere and then implement BMP where performance is important enough to pay the price for longer development time.

It has been very interesting and challenging to work with EJB and persistence.

The EJB architecture looks very promising for distributed server applications in Java. I hope and think that my work here will make it easier for software developers to design and implement EJB applications in the future. Though my work was limited to the persistence mechanism of EJB I hope that this part of EJB will be easier to grasp and implement as well as possible.

As for future work it would be very interesting to evaluate the use of object- based databases in conjunction with EJB. This might prove to be an attractive alternative to the relational database.

When starting my work on this thesis I had hopes of being able to test at least one strategy in a real life environment. This could unfortunately not be done, mainly due to lack of time.

5HIHUHQFHV

[1] Sun Microsystems, (QWHUSULVH-DYD%HDQVVSHFLILFDWLRQ, 1998 [2] 5HPRWH0HWKRG,QYRFDWLRQ50,, http://java.sun.com/products/rmi,

31/08/1999

[3] -DYD1DPLQJDQG'LUHFWRU\,QWHUIDFH-1',, http://java.sun.com/products/jndi

[4] (QWHUSULVH-DYD%HDQV7HFKQRORJ\, http://java.sun.com/products/ejb, 31/08/1999

[5] ,QWHU%L]])LQDQFLDO6\VWHPV, http://www.ibfs.com, 01/09/1999 [6] 52;http://www.ibfs.com/p_suit_rox2.html, 01/09/1999

[7] %($:HE/RJLFVHUYHUKWWSZZZEHDV\VFRPZHEORJLFVHUYHU

$SSHQGL[HV

Appendix 1 gives definitions of the different strategies evaluated. The acronyms used to reference each strategy are also stated here.

Appendix 2 contains the specification of the test environment used when implementing and testing the strategies.

Appendix 3 consists of formal definitions of the measurements that were used when evaluating the strategies.

$SSHQGL[

Definition of strategies:

CMPA – Update all always as fields

Whenever a business method has finished its execution all fields are written to a row in the database.

CMPB – Update all when modified as fields

Will update all fields against a row in the database, but only if at least one of the fields in the bean was modified.

CMPC – Update all when modified as blob

The table in the database consists of a primary key and a BinartLargeOBject field (BLOB). When a field has been modified, all fields are stored in the BLOB.

BMPA – Update all always as fields

After each business methods all fields are stored in a row in the database.

BMPB – Update all when modified as fields

All fields are stored in a row in the database when at least one field in the bean was changed.

BMPC – Update all when modified as blob

Stores all fields in a BLOB in the database when at least one field in the bean has been changed.

BMPD – Update changed as fields using business methods

Each business method updates the fields that it has changed against a row in the database.

$SSHQGL[

Client and server machine:

• Architecture: SPARC sun4u 266 MHz processor

• Operating system: SunOs version 5.7

• RAM: 512 Mb

Virtual machine: 6XQ-DYD-'.

Database: 2UDFOH(QWHUSULVH(GLWLRQYHUVLRQ

EJB Server: %($:HE/RJLF6HUYHU

JDBC driver: 2UDFOHL-'%&GULYHUYHUVLRQ

$SSHQGL[

Measurement definitions:

Flexibility Gives a hint of how complex data types the strategy is capable of handling. Included in flexibility is also the ability to support a variety of different database vendors, if a strategy makes this hard it is considered to be inflexible.

Performance Pure performance is how fast the strategy is capable of doing an update against the database.

Scalability Shows how well a strategy can handle an increase of concurrent clients.

Complexity This is a subjective evaluation of how complicated it is to implement a strategy. High complexity is considered to be bad since it increases time-to-market.