A couple of weeks ago I was trying to resurrect a 3 yr-old project, implemented using WebLogic 6 in Linux, into a working web application using OC4J 10gAS in Windows XP. Here are some notes I made during the process, which might help anyone doing or planning to do the same:
1. Do not rely on vendor specific deployment descriptor. If you have to, use the same name everywhere. Back in 2001 when EJB was still a new thing, WebLogic offers weblogic-ejb-jar.xml as a vendor specific deployment descriptor, in combination with the default ejb-jar.xml. The mapping between the names in the default ejb-jar.xml and the weblogic-ejb-jar.xml differed in our implementation. This has caused a great deal of problem for me migrating it, because OC4J does not read the weblogic-ejb-jar.xml.
2. OC4J requires adding "java:comp/env" prefix when performing a JNDI lookup to find the instance of local ejb. This certainly is different from the WebLogic implementation.
3. There was a bug in OC4J 9.0.3, following are the extract information from their official site:
Using <jsp:include page="xxx.html"> with html files greater than 20K causes an exception. If the included HTML file size is > 20k you will encounter java.lang.StackOverflowError. Currently, there is no workaround, other than to keep the file size < 20KB. The bug is being fixed and will be part of next update.
This certainly caused me trouble, since the application used a lot of <jsp:include> where one or more of them may be of 20 KB size or more. The only solution was to upgrade to OC4J 10.x.
If you guys have any other experience in migrating J2EE application from one application server in one platform to another application server in another platform, please collaborate..
I'd really like to know.. :D
Further Reading:
J2EE Performance Testing with BEA WebLogic Server
Oracle Application Server 10g Web Development
A colleague of mine recently had his transaction thwarted because the EJB container (OC4J) timed his transaction out. The default setting is 60 seconds, and he's still running the test in his own desktop with only a single user accessing the transaction. It is quite unacceptable for a transaction to exceed 60 seconds limitation while it is still in development stage.
The transaction includes many reads to the DB, before actually updating one record, and inserting many new records. As most developers who are unaware of the EJB transaction attributes and their respective meanings, he also set all his methods in the SLSB as Required. This would have all of the methods which are part of the transaction to be included in the transaction, when there are many cases that they may not. The transaction itself spans a great length, starting from the very first method in the SLSB, going through many other methods in the same SLSB, or in the other Session Beans, until finally return from the entry point method.
I tried to optimize this by learning the business algorithm behind the transaction, then changing all read accesses to NotSupported, and leave the write access to Required. This has significantly reduced the transaction span time. But still, I had to change the transaction time out limit to 4 minutes. This is still unacceptable.
After measuring the time it took for each processes, I found out that the transaction is trying to insert 15 records to a database table. Each record requires a FK field to be set, and each of this FK field has a different value (for the 15 records), and requires a database access to retrieve the object. Why? Because we're using ORM, i.e. Toplink.
In Toplink, I don't know how they do it in the other ORM technology, before you insert into a child table, you'll need to find the parent object, and set it as the FK field's value. Then, you insert the child.
This type of programming style leads to defficiency in many developers' code. So, what I did was I created another method to query these parent objects (based on whatever information I had), before I try to insert the 15 records into the database. I put the query result into a Map, which will be used by each of the 15 records as the lookup base for their respective FK field's value.
This approach worked very well. It reduced the 20 seconds access into 1.5 seconds. There are still many inefficient code lying around his package. But it's one refactoring. There will be more, of course. The transaction time out limit has been reduced back to 60 seconds, and all went well.
The question remains, does ORM tend to lead inefficient DB access, if performed recklessly?
Further Reading:
Head First EJB
Expert One-on-One J2EE Development without EJB
Bitter EJB
Over the weekend, I took the chance to watch the videotape of Mark Eagle's Introductionn to Spring in front of Atlanta JUG Meeting back in July 2004. The videotape was very good, even though it's mainly focusing on the presentation but not covering any of the audiences. I learned a lot from the presentation, and I'm suggesting anyone else to do the same.
It's a two-hour presentation, packed with good stuffs. Even though it's probably best to be there myself, watching a presentation which can be reversed and repeated over and over again, until I get the point, is also good.
So again, watch the videotape here, and let me know what you think.. :D
Further Reading:
Expert One-on-One J2EE Development without EJB
Spring Live
Spring in Action
I don't know how the other O/R mapping technology, such as JDO or Hibernate, commits the changes into the database, but Toplink has an interesting behaviour when using the transaction from EJB container.
First, Toplink will remember all database updates (insert, update, and/or delete) being performed within a single transaction. Then, only after the method in which the transaction started exits, and when the EJB Container is about to close the transaction, Toplink will try to generate the SQL statements required to perform the above actions. Toplink then executes these SQL statements, in an order specific to Toplink's dependency algorithm which might differ from the order in which we instruct them to (within our code).
If and only if the database accepts all these changes, then Toplink updates its caches, and return the control back to the EJB Container which will successfully close down the transaction and return back the needed values to the client. If, for example, there's a database exception thrown during the commit phase, the catch block or any other code within our EJB code will not be invoked. Instead, the code of the EJB client will be the one who is supposed to handle the database-related exception.
Why? Because the exception were thrown after the EJB method completes, but before the EJB Container returns the control back to the EJB client. This is troublesome sometimes.
Well, I haven't learned much about Toplink nor any other O/R mapping technology, but is this the ideal approach?
I hardly believe it.. :D
Links:
Links:
Hibernate in Action
More Hibernate books
More JDO books
