Skip navigation
1 2 3 Previous Next

Andrew Oliver's Blog

45 posts


Greetings from Germany. Why Germany you ask? Why not Germany? Especially this time of year. Next, I go to Santa Clara and run off at the mouth at AJAXWorld. In the mean time I've been running off at the mouth electronically about performance over at Red Hat's 108 site which is an abbreviated, not live and less specific version of what you can get from the next JBoss ON the Road. I hear it is a good show. Though I hear they do not have monkeys or meerkats. However these wild animals from the SE team will fill your brain with ways to make your system get up and walk by itself. Boy the coffee in Europe is really good. Almost as good as the Hawaiian Kona I bought at Bean Traders whom I'm considering taking them up on "a deal" and getting their logo tattooed (free coffee for life baby) somewhere if I can only convince my wife to let me. Albiet from this post you may be of the opinion that I don't need any more coffee or potentially that I've been taking writing lessons from Marc... :-O Tschüs (but don't say that to someone who speaks Hindi or Urdu because it sounds like something else).


I'd like to announce the 1.0M5-pre1 (webstart install, download) pre-release of JBCS. This release realizes the integration of Calendaring and the addendum of our Mail Client. We also have alpha-stage IMAP support for Mozilla Thunderbird 1.5 (or so I will confirm as I've been using it for awhile now). However, Jason Pugsley was kind enough to work on OS X's and Outlook just before I cut this release and submit some patches! I couldn't help but put those in. We could use some help testing there of course!

  • alpha quality IMAP support for at least Thunderbird 1.5
  • Calendar Server integrated
  • Web 1.0-style calendar application (deprecated by JBCS 1.0)
  • alpha-quality user APIs for MBAs and CBAS type applications
  • JBoss Collaboration Client (presently "webmail" only) in beta quality
  • Administration backend support (needs a front end)
  • overhaul of naming/security deployment


If all goes well then we will release a final by next Monday at the latest. I do not anticipate any deltas between the "final" and this version other than some text. Documentation will be appearing here as the week goes on (a difference between a PRE and a Milestone). The instructions for M4 should also apply. However if you would like to try out IMAP, you will need to uncomment it from the $JBMS_HOME/server/default/deploy/mail.ear/mail.sar/META-INF/jboss-service.xml config file (it is near the bottom). The installer does not offer it because we consider the IMAP to be alpha-quality only (though I'm using it).


Additionally, don't forget to try out our hot new rich mail client which is included in this release! I appreciate the emails of congratulation that I've been getting off of our live demo of the client and simple Collaboration Based Application Service (CBAS) demo. Please keep them coming. It is great to see people "getting it" after all of those late nights! I've shared some of them verbally with the core developers of JBCS. Please feel free to join us in the now mis-named forum. And remember the 1.0 final release will premere at JBossWorld. I hope to see you there.


We're in the process of rebranding JBoss Mail Server. The 1.0 release will be called JBoss Collaboration Server. To be clear JBoss Collaboration Server includes:

  • JBoss Mail Server (now refers strictly to the mail server)
  • JBCS Secure Administrator (in progress)
  • JBoss Calendar
  • JBoss Mail Client (now referred to as "webmail")
  • Mail-Based Application (MBA) and Collaboration Based Application Service APIs


Prior to this we had no clear way to refer to the whole project versus the mail server component. It also names us more clearly where we belong in the market.


We will begin this release with two live demos in one. First of all I want everyone to see our new web-based mail client. However, I also want to introduce you to some terminology: Mail Based Applications and Collaboration Based Application Services and give you an example. First, linked below is the mail client. It requires the Flash 8.59 beta which you can download from here. It presently is available for OS X and Windows. There are statements from various people at Adobe about a release for Linux coming out shortly after the June release of Flash 9. I really hope that is pursued more agressively as testing has admittedly been difficult since I can't test on my Fedora (AMD x64) laptop and even Flash 7 (the last Linux release) doesn't run.


Click here to run the demo


Here is a couple of screenshots so that you know it is worth your time:



Use any of these accounts:



In our scenario. Assume guest and guest2 might be remote (but for the purposes of the demo I have disabled all remote mail capabilities). Guest is an employee of some agency of the government and has the mail address Guest2 is an employee of a potential partner of BigCo our fictitious company. Sales is our main alias for sending sales inquiries, its even listed on the BigCo webpage. Partner, is the account manager who runs partner accounts. He's based in Texas. Gov, is the account manager who runs the government accounts.



We have two custom JBMS Mail Listeners. One inspects mails to If the domain ends in ".gov" then the recipient is changed to "". However, we also add the mail to the Government Account Manager's Calendar for a follow up looking for the next available gap starting tomorrow.


The second mail listener checks to see if an incoming mail to contains the world "partner" in the subject or body. If so then it reroutes the mail to the "partner" user and adds it to the "partner" user's calendar with the same algorithm as the gov user.


TRY IT OUT!...but if you're hoping to be a troll know that we delete the DB every few hours with a cron job and remote delivery is disabled :-)

  • log into the application as "guest" with the password "guest"
  • click "New Email"
  • make the To: <>
  • select "" in the From
  • make the subject "Hello I'd like service"
  • type in a body "bal bal bla"
  • Click send
  • Click logout
  • log in as "gov" password "gov"
  • click on the calendar for tomorrow... You should see a "follow up with..." event on the calendar... If there are a lot of events it may be the following day.
  • you can do the same thing by logging in as guest2 and including the word "partner" anywhere. then login as "partner" pw: partner


You can find the source for these examples in the jboss-mail CVS module under src/examples. Note that the above webmail is still in development and is developed using Adobe's Flex product (which outputs to swf aka Flash format). We are looking for more volunteers to help out Adobe Flex Genius James Ward. If you are interested in learning flex download the free (as in beer) Flex 2.0 beta 3 SDK post to the JBMS forum. Next, join us in the #jbms room on The MBA/CBAS api is also under development so do not consider these stable APIs just yet. JBCS 1.0 debuts at JBoss World! I really hope to see you there!


Tomorrow you'll be able to download JBCS 1.0M5-pre1 here and try it out. This is intended for the JBCS devotees and enthusiasts who help us test. Documentation will begin appearing over the week and with any luck JBCS 1.0M5-final will be out by the end of the week. Commercial service and support will not be available until after the 1.0 release. Until then you can email inquiries to ( and join us in the JBCS forum.


I'm nearly as hot as JBMS is right now. I am sitting in my house and it is 84 degrees inside because the air conditioner that we just recently bought is broken again. After working some crazy hours last week, I had planned to sleep, but try sleeping while drenched in your own sweat! Anyhow, I'm using some of this "extra time" to bring you all up to speed on the state of JBMS's development.


First lets talk about JBMS 1.0M4 (install). I'm pretty proud of that release. It really pulled memory consumption down and has been really a treat on my server, especially since I discovered how to do maintenance on PostgreSQL (vacuum analyze). Of course, you'd never notice since I had a little hardware issue (that server is cursed I say). Since that release, we've had over 12,000 downloads according to our download stats (if that's not right...blame our IT guy -- he likes it).


M5 is proceeding according to plan. The schedule in JIRA for it says March 31, but we never intended to release on March 31, that was arbitrary because I didn't know when the event we were shooting for was going to be scheduled. The real goal was to have as much of a certain set of features demonstrable for an internal JBoss meeting as we possible could (which the major active contributors are participating in and they're bringing the ponies) -- then release shortly after. Those features and their status:

  • IMAP (good enough for Thunderbird) - Done minus "search"
  • WebMail - This is the most spellbinding thing. Boy the less industrious of you are going to pee your pants when you see what we've done in a short time (I figure the more industrious will probably compile it from head and ruin the surprise -- open source is bad for surprises). Some other folks who I won't name are probably going to see it and get a bad headache since we're closing in on them and will pretty easily overtake them. FYI we used Adobe Macromedia Flex for this. Flex is a free as in beer rich GUI framework (based on Flash) from Adobe's Macromedia.
  • Calendar - The backend is pretty much in the bag. There is a pre-existing web-based application and we're working on the rich GUI as part of the WebMail client.
  • APIs for Mail Based Applications (MBAs) - MBA support is a critical goal of JBMS; however, we've been avoiding solidifying the APIs because we didn't want to limit things. As of the M5 release we're on track to have some less moving targets for MBAs to call to. This won't be the final say (hey it won't be final until JBossWorld), but we're well on track
  • Video - So many of the other JBoss projects out there have cool little video demos and podcasts and stuff. We're not really the types to do that, we're more likely to pop open a hex editor. However, power to the people and since you asked, I downloaded this little proggy for my Powerbook and made some internal demos. It seems to work pretty well! So with this release I'll try and include some A/V to our usual wiki-based fare -- well if the demo doesn't expire by then or if I can scrounge up the $70 from somewhere.


When M5 comes out, I fully expect some very ambitious people to put the IMAP part into a large production farm, but I want to be clear that just getting IMAP working well enough for ThunderBird isn't full IMAP support by any stretch of the imagination and there are places where our "low memory consumption" (aka the Store api) optimizations haven't been made for IMAP just yet. So while I don't want to discourage the ambitious, I want to be clear on what you're getting into. IMAP will be ready for personal to small group IMAP using Thunderbird by M5. I'm hoping to get a chance to work on Outlook but that will probably have to wait for M6. If I don't fall over from exhaustion or heat stroke, I think we'll have M5-pre1 by near the end of the month -- and if there are no horrible bugs (or JBAS releases) then it will get smoothed and rolled into M5-final.


So if you CAN'T wait and are planning to check everything out from the head and install it, then you're probably exactly the kind of person we'd like to be chatting with in IRC ( /join #jbms) and the JBoss Mail Server Forum or maybe even hacking JBMS source with us!


And remember... we JBMS developrs don't love you (sorry), but we think you're pretty okay and want to write great software for you,


Go register for JBossWorld right now. You'll save $200. Make sure you don't miss the JBoss Mail Server session. The rest of the show should be good too. Last year the place was packed. I think most people who went last year would probably return just for the party:


JBossWorld Atlanta 2005


I imagine Las Vegas will bring an interesting twist to whatever we do this year...

Most people don't know what RMI DGC is. And most people don't need to know what RMI DGC is. However, if you run JBoss Application Server on Sun's VM, RMI DGC is probably sucking the performance out of your app. Whether you use RMI or do not use RMI, JBAS causes RMI to be loaded. By default, the RMI subsystem forces a full garbage collection once per minute. This means that all threads are paused and the entire heap is scanned. This takes a good while, especially under load. To change this behavior to once per hour edit your $JBOSS_HOME/bin/run.conf as follows:


   # Specify options to pass to the Java VM.


   if [ "x$JAVA_OPTS" = "x" ]; then

     JAVA_OPTS="-server -Xms128m -Xmx128m \

-Dsun.rmi.dgc.client.gcInterval=3600000 \



The \ characters above are intended to be line continuations rather than literals (so don't put them, just put it all on the same line if you like). Obviously if you changed the heap size then the above -X params will be larger. I've changed the startup script in the 4.0 branch and head so in the future releases you won't need to do this manually.

The System.gc() call that the spec says may not do anything or may do something actually triggers this full garbage collection. You probably don't want any code doing that (including the RMI DGC) so rather than the above you can add XX:+DisableExplicitGC and never have forced full GCs. By default you will still see a full GC (in Sun's VM) once the heap reaches approximately 70% utilization (the ratio is configurable).

So when do you need this default RMI DGC full GC behavior? Approximately never, but if you do a lot of remote object calls (EJBs) and don't cache your Home or Remote objects then MAYBE once per hour won't be enough. For more of these tidbits read Tuning Garbage Collection with the 1.4.2 Java[tm] Virtual Machine. If you DON'T want to become a GC expert (especially if you have a multi-processor machine) then you probably should upgrade to JDK 5 as it will pick more sensible defaults for your platform. (JRockit or Sun recommended. IBM's VM is pretty buggy and has a retro garbage collector.) For JDK 1.4.2, JRockit already tries to autotune. Sun JDK 1.4.2 defaults to a single threaded generational but slow GC.

What other semi-mornic defaults lurk to find you? Well one of my favorite is the default thread stack size when you throw on the "-server" switch. If you've been using Java for awhile then you may remember running out of stack space in JDK 1.x. That's because the default was something like 16k. Well today's systems have a default that is much higher -- in fact on most platforms "-server" means 512k stack per thread in 32bit mode and a whopping 1MB per thread in 64 bit mode. Since this is allocated OUTSIDE the heap, lets think about what that means... Assuming I've set my VM to 1.3g on 32-bit Linux w/o large memory pages enabled -- I've got about 700MB to play with. In any large app, 128M of this is probably going to Perm space (where my class definitions are compiled) which leaves 572M. Take maybe 100MB for "stuff" and we have 472M. So 472M is about 944 threads. Which sounds like a lot and is probably an overestimate (or 100MB for "stuff" was an under estimate), but in large systems 944 threads can be eaten up quickly especially with thread pools (Tomcat alone is probably holding onto 300 of these by default). Unless massively cyclical recursion is your favorite way to write business code, 0.5MB per thread is probably a bit big. On Linux you seem to get a plain OutOfMemoryError. On Solaris (4G max process space with 32bit vm) you get "cannot create native thread" plus an OOME. Change this by passing "-XX:ThreadStackSize=128" or if that isn't available on your platform then "-Xss128k" may do the trick by itself (generally it can only set the number higher and not lower). Test this of course, you may need more than 128k (256k is a nice conservative number).

So there is a lot more to be done about VM tuning in any large app, but these two sets of switches consitute the "go fast" button and the "please work" button respectively. Maybe next time we'll talk parallel and concurrent GC or why IBM's VM is yucky and JRockit is goodness. Until then, just remember that Sun JDK 5's parallel and concurrent GC are much more stable than 1.42's and upgrade if you haven't already.

Just so you know the blog thing kinda has grown bigger but started out as a crappy looking webpage (blojsom used to be well written but crappy looking - now it is pretty) on my personal server. I begged and whined at people to post. Then MarcF became a believer and he beggged, whined and then posted "blogging manditory" :-). Then Roy Russo and others realized that this gets their project more traffic and every other post became about JBoss Portal ;-)... So I realize that when I turn off the comments that there will be conspiracy theories abound as to why (such people will probably miss that I posted that I WOULD turn the comments off if they became a pain for me in the very first post on here).

Just so you know, I am the guy who goes and moderates all the spam and the unofficial but Matrix-actual (remember that BSG is on tonight). And I don't have time to delete all the medical enhancement ads (and similar content) from our comments. Moreover our corporate communications policy does not include providing a forum for comments of a sexually explict nature or comments offensive to people's race, religion, nationality, etc (you missed it but someone actually managed to offend me AND the "bile blogger" in the same comment thread). Nor are we interested in being a Spam receptacle, for that reason the blog comments are disabled henceforth. That DOESN'T mean the two way communication has to stop, just change venue. We have forums related to the blog and general discussion, places to shoot the..whatever. Just they self moderate better because spammers don't generally register first and more people watch them. So If you'd like to discuss anything you see in the blog go to The Lizzard's Corner or the relevant topical forum. Or download and install JBoss Mail Server and use it to send me an email and I'll probably chat or post it for you in the forum. Or if its JBMS related there is also IRC ( /join #jbms).

Remember to have fun and that blogs and blogging rots your brain.

Update: So this caused the paranoia (and cheap shot) that I feared it might. Note that this change is only temporary as our new site which is to become jboss.ORG has the technology to do what we want (comment w/registration) which I note is not what *he* actually turned on (he turned on moderated comments which means he has to agree w/you first)...where ours were completely open to all spammers.

[acoliver@colo-br-02 acoliver]$ find /home/jboss/blog/jbossBlog/  \

          -type f -exec grep -li "viagra" '{}' ';'|wc -l    471


[acoliver@colo-br-02 acoliver]$ find /home/jboss/blog/jbossBlog/  \

          -type f -exec grep -li "texas" '{}' ';'|wc -l   1662


[acoliver@colo-br-02 acoliver]$ find /home/jboss/blog/jbossBlog/  \

          -type f -exec grep -li "sex" '{}' ';'|wc -l     34


[acoliver@colo-br-02 acoliver]$ find /home/jboss/blog/jbossBlog/  \

          -type f -exec grep -li "java" '{}' ';'|wc -l    192


[acoliver@colo-br-02 acoliver]$ find /home/jboss/blog/jbossBlog/  \

          -type f -exec grep -li "jboss" '{}' ';'|wc -l    620

Our readers are geeky enough that I would expect java and JBoss to show up in their post more often than the other key words :-). I don't mean to be defensive but I took the implication that I was lying as to the reason rather personally. -ACO


JBoss Mail Server 1.0 Milestone 4 is a full POP/SMTP email server supporting virtual hosts, SSL, TLS, and multiple different databases (including specific effort to support Oracle, PostgreSQL, and MySQL). Although this is a milestone release JBMS has already been deployed at a number of corporations and research institutions. You may download or install it (via webstart) here. We do strongly recommend following the instructions, I mean the how to has pictures even and the process for creating users/mailboxes is different from prior releases.


First, I would like to express gratitude to all those who have provided feedback about last week's pre-releases, and in the ongoing poll.


This release is strongly suggested for anyone using 1.0M4-pre1 or 1.0M3 and earlier. It is optional for those who installed 1.0M4-pre2 (there are only changes to documentation, versioning and the installer).

Some of my coworkers have implied that we put out far to many pre-releases and that release is not approaching fast enough. We plan to put out the 1.0 once JBMS has IMAP, WebMail and a graphical administration tool. This is presently scheduled to coincide with the JBossWorld event in Las Vegas (the plan has not changed).


As always we appreciate your feedback and participation in the JBoss Mail Server Forum


Norm Richards will introduce SEAM at the Dallas JavaMUG. Read more at Norm's blog. Tell Norm how much you wish he'd announce such things HERE well in advance :-).


After yesterday's JBoss Mail Server M4-pre2 release announcement, we could use use some help prioritizing post M5 work. Since IMAP is pretty well regarded as the most important feature, it is the focus for M5. Following this we have a list of other objectives and would like YOUR opinion on which is the most important to work on next. Please vote and thank you for your support.


You may download M4-pre2 here and find installation instructions for JBMS M4-pre2 here. It is highly recommended that you read the installation instructions as you must now create aliases for users as a manual step (as mentioned in the prior release).


Last week I announced the M4-pre1 release of JBoss Mail Server. Since then we've:

  • fixed several stability and memory consumption issues
  • resolved database portability issues
  • upgraded to JBoss EJB3.0 RC5-PFD
  • significantly improved performance (over both M3 and M4-pre1)


In all likelihood this will be the M4-final release with only potential changes to the installer and update of the documentation/version numbering. It is highly recommended that anyone who installed the M4pre-1 release immediately upgrade to this release as the fixes to the release were of significance over the previous pre-release.


This version includes a distribution of JBoss Application Server 4.0.3SP1 which has been upgraded to the EJB3-RC5-PFD edition of EJB3. It will not likely install properly over an existing JBoss Application Server prior to the upcomming 4.0.4 release without manual modification (sorry). It is suggested that everything else in the prior release's announcement is still relevant. Documentation will continue to pop up as we get feedback and in correlation with M4-final. As always we appreciate your feedback in the JBMS forum and thank you for your support.


ALSO: please vote on what features you'd like us to focus on next.


You can now download the JBoss Mail Server M4-pre1 release for JDK 1.5 here.


This release is our first pre release of the next milestone. It has undergone dramatic internal improvement from the M3 release. Therefore early adopters should treat this "pre" release with more care than previous "pre" releases. This release includes (among other things) these major features:

  • Virtual Hosts
  • Aliases
  • SMTP Relaying (via mail routes)
  • APOP
  • TLS for POP
  • numerous additions to the installer


The installation process now includes some post installation tasks that the administrator must complete. Moreover, some screens for enabling complex features may not be obvious. Therefore, we recommend that even users with prior JBMS experience view the installation walkthrough. While much of the documentation for this release is already updated, it will not be finished until the actual 1.0M4 milestone release.


For users who chose to use Microsoft Outlook, we now have instructions for setting up Outlook for use with JBoss Mail Server available on the wiki (common settings). For users using Mozilla's Thunderbird open source product, we also have updated instructions for setting up Thunderbird for use with JBoss Mail Server. While these are the most common mail clients we are willing to publish instructions for integrating other commonly available mail clients with JBMS, please offer suggestions in the JBoss Mail Server development forum.


Although the winter season saw a pause in development, adoption and interest has been steady in JBMS and we have now begun to attract contributors from competitive and complementary efforts. This is primarily due to the open nature of our community with its "do-ocratic" viewpoint where some projects have become increasingly stagnant due to their own social aspects. It can also be traced to the fact that going from small to large can be achieved faster than going from large to much larger. Still we would like to see more potential contributors live up to their potential.


As previously emphasized, user installation experience is a continued focus for the project. We think that we are already the easiest to install mail server on the UNIX platforms and positive feedback at JUGs have indicated that we are also doing well on the Windows platform. We would like to hear about your installation experience positive or negative in the JBoss Mail Server development forum as well as any suggestions you may have to improve it. A challenge in maintaining our progress in this area is offering a good set of features without overburdening the average administrator with settings that he/she will never need. Moreover, it is obvious that some tasks should be in the domain of post-installation administration. To this effect, I do think that M4-pre1 is a minor ease-of-installation regression over M3 in that there are more screens in the installer and creating mailboxes presently involves confronting the much-hated JBAS jmx console (you could also use the web console but then you loose the friendly CTRL-F key for all intents and purposes). Rest assured this issue is foremost on my mind. We are looking heavily into the area of administration experience. Although I anticipate that we are close to a "production" release (if not already there), I will be reluctant to stamp a release with the 1.0-final blessing until we have both webmail and an administration tool.


I hope to apply further performance optimizations over the next week. While most of our load testing was done before a crucial mailbox re-factoring, we expect some performance improvement. Still, we are aware of a number of places where there are opportunities for improvement (particularly in the new mailbox layer). However, my wife said "Ooooh...the mail runs much faster now." which probably means we did okay here :-).


For the M5 release (which will have a much shorter cycle) we will primarily focus on IMAP, but will of course be looking to improve the administrative/installation experience and hopefully see a sophisticated webmail begin to emerge. Please report problems and suggestions to the JBoss Mail Server forum.

Having done a fair amount of Hibernate training and consulting, I thought I might post this mini-guide on some common tuning things. These are the top 8 things I tend to find when tuning Hibernate/EJB3 apps. I am going to talk about this predominantly in Hibernate terms but most of it applies to EJB3 persistence (some of the detached object/etc stuff is a bit Hibernate specific) as well. All of it obviously applies to JBoss's EJB3 persistence implementation (which is Hibernate) either by default or through the use of "extensions" (is it an extension if it predates the spec?).

  • appropriateness of Hibernate for the task
  • fetch strategies
  • set logic vs iterative logic
  • named vs adhoc queries
  • cache abuse
  • version columns/locking strategy
  • bah...DB2 and friends
  • flushing your performance

appropriateness of Hibernate for the task

It may surprise you to read that sometimes the first thing out of my mouth to customers is "I really am not sure you should be using Hibernate for this". Too often I see code that could take seconds as a few "update/where" and "insert/from" type statements written as a set of iterative loops. Now this bad code was traditionally written as PL/SQL with cursors but is now written as Java with Hibernate. The problem is that if the PL/SQL code was really slow, the Java code is ridiculously slow (do to interprocess/network communication). Generally the "reason" is that they "want to reuse our business logic for batch processing". The problem is that improper cost/benefit analysis is done. If you "reuse your business logic" and it takes 10 hours for your batch process to run when it could have taken 10 minutes...was it worth it? This comes up frequently in computing. It is "performance vs maintainability" and traditionally the answer is "maintainability and buy a faster processor. The problem is that this is all about "how we do IO" and "how many processors are used to do the task". When we talk about millions or billions of records being processed the decision matrix tends to shift in favor of hard to read Oracle-specific SQL statements with bizarre "parrallel(x)" syntax running efficiently in the database. Using cursors and iteratively processing these in loops performs poorly and bound to a single processor. Performance is even worse when doing remote communication by using a Java resultset for sequential access. Hibernate is really appropriate for transaction processing where we have short sweet reads, writes, and updates happening over many threads. The scale is in concurrency and pause time rather than in records processed.

fetch strategies

Many users define their fetch strategies inside of their meta-data. In Hibernate, you can put it in your HQL query instead which allows you to tune on a use-case basis. In H3 when you run an HQL query the mapping file's fetch strategy is ignored for each association and they are loaded lazily by default. Speaking from a performance perspective only, your DAO classes should reflect "use cases" such as "findCustomersAndOrdersByXXX()". This is a great advantage over definition defined fetch strategies as I may sometimes only want customers and other times I may want customers and orders. It depends on whether I am about to show the customer his address or about to show a sales person his detailed order history. You may wish to separate data access tiers, but should not do so in a way that is naive.

     from Customer c left outer join fetch c.orders

set logic vs iterative logic

This item overlaps the stuff mentioned above in the appropriateness of Hibernate issue. Unless I have already loaded a set of data into my session cache, iterating through a set of data and updating a property is often inadvisable. Meaning I should not load a customer, loop through his orders, have a condition and call setStatus(STATUS.FOO). I should write this using the "executeUpdate()" EJB3/H3 method. This lets me write a SQL-style "update" statement (as well as delete, etc).

   update customer c set c.status=:status where c.status=:prestatus and c.territory=:territory

named vs adhoc queries

Hopefully most of you use Hibernate with an appserver. If you do not, I know where you can get a great one for free! Your appserver should supply a connection pool. Your connection pool should supply a statement cache. When you use named queries, you optimize the use of the statement cache. Meaning Hibernate will pre-parse the HQL, create the statement and have it ready to go for named queries. For an "ad hoc" query this happens every time on the fly. For EJB3 this means using the appropriate annotations for named queries. This can make a difference in performance, but the main advantage is that any HQL errors are discovered at startup rather than on the fly.

cache abuse

Cache is King, but it can also be king of bad performance. I generally recommend turning cache on at the end of your project as part of your performance testing effort. However, most developers fundamentally misunderstand how Hibernate uses cache. Cache is not, by default, on at all. Turning second level cache on, does not effect HQL/QbE/QbC/SQL queries. Caching with a low cache hit ratio will result in decreased performance due to de-optimization of the JVM garbage collector. Caching forces memory fragmentation. Caching expedites major and full garbage collections. Second level cache, primarily affects Session.get/find/load operations as well as association traversal (but less so). Query cache affects queries, but has to be turned on for specific queries. It is keyed by the query and its parameters. This is good for things like list boxes. The only automatic caching Hibernate does by default is Session caching. Meaning when you access entities through the session they are kept referenced in the session. If you access the same entity twice through Session.get/find/load then it is retrieved from the session cache.

version columns/locking strategy

Most developers don't understand how most transactional databases work (see DB2 section for a more in-depth discussion). When you have a transaction in the data you update is a "copy" of the data. It is only saved over the original when you commit. However if two concurrent transactions update the same data, the default behavior is "second one wins". Much of the time, we want "first one wins, second one is informed". Hibernate can help. One way it can do this is to keep a copy of every field read and execute a statement like this:

update thing set description='something in the db' where id=1 and date='10/10/01' and description='this here thing'

Meaning all of the original values are in the where clause. In order to do this, the session must remain open which precludes the use of detached objects (for all intents and purposes). However, Hibernate also supports the use of version or timestamp columns. In order to use them, you must have a version or timestamp column in your table. You should have one anyhow, because even if Hibernate isn't your exclusive access method, you can do this without Hibernate:

update thing set description='something in the db', set version=2 where id=1 and version=1

Even if the above DML SQL was executed twice, the second query would return "0 rows updated" which Hibernate uses (via JDBC) to generate an exception to the second updating thread. This is an efficient way to implement optimistic locking and it of course works with detached objects. Obviously you can adapt legacy code to do this as well. While some data do require a LockMode.UPGRADE or "select for update", much data do not. The great thing is that Hibernate manages the version matching/logic for you, you just catch the exception and decide what to do about the conflict.

DB2 and friends

With IBM's DB2(/Informix) you get to do fun stuff like monitor lock contention. The big issue with DB2 is that it doesn't support something called Multi-Version Concurrency Control (MVCC). What is it? Well this article gives a high level explanation, but basically you work on a copy of the data in your transaction rather than on the real record; when the transaction commits it is written back. DB2 supports row or page locks basically. Which means in the normal/default/usually-optimal "read committed" isolation level DB2 will get a read lock on rows read in a transaction when Hibernate issues select statements. This could result in very slow performance if you have lookup tables that are not/cannot be cached for instance. Your options though suck. You can degrade the isolation level to "read uncommitted" (you do this in the datasource definition in JBoss). Since Hibernate uses a "write behind" strategy, you can used this as a "poor man's" MVCC. Meaning so long as you do not actually flush to the database, you're going to achieve most of what MVCC tries to achieve. However, you have to be aware of the flush mode behavior of Hibernate. There is a lot more to all this and if you have to use DB2 (you'd have these problems with or without Hibernate) and you don't know all of this already then you probably need help if you're going to achieve a high level of concurrency. With all of that being said, while DB2 costs a lot less than Oracle, I can't say enough about how much more optimized for transactional computing Oracle is. However, Oracle is not your only option, this is not really a cola war. You actually can choose from several databases with MVCC or forms of MVCC including: Microsoft SQL Server, MySQL and PostgreSQL. DB2 and Informix are basically left out in the cold here with regards to "popular" databases without MVCC. In fact glaring are the benchmarks published by MySQL. I'd put to you that MVCC support is probably more important than a lot of other concerns in transactional computing (as opposed to batch processing and OLTAP type stuff). If licensing was the reason DB2 was chosen over Oracle, you may want to consider one of the other database choices. Aside from Oracle, I have had the most experience with MySQL, but they have great service and support and with what you save on licensing you can probably buy some fatter hardware and possibly exceed the performance of the others for far less money.

flushing your performance

Finally, a lot of developers call session.flush excessively. Note that the default flush mode (auto) in Hibernate flushes data whenever a query is executed or whenever a transaction is committed. This makes calling flush normally unnecessary. It also means that if you do query, update, query, update, query, commit that flushes will happen at least 3 times. If we do query, query, query, update, update, commit and change the flush mode to COMMIT (instead of auto) then we could achieve the same thing with only 1 flush. Flushing is pretty expensive (it is when all the DML is sent to the DB). Economizing this would be good from a performance perspective. However, if you have a lot of junior developers on your team (or careless people) then it is pretty hard to work in a FlushMode.COMMIT world. Meaning if I update'foo' and then execute "from thing where name='foo'" I will not get back the thing I just updated as a result. You have to manage your own transactional space with regards to your own updates in a FlushMode.COMMIT world. However, it is good from a performance perspective (meaning I wouldn't recommend it much of the time). In looking into this you may also want to look into the jdbc batch_size setting.

While in most apps your performance tuning should start with your persistence layer, it should not stop there. Moreover, your settings in the persistence layer touch your appserver configuration (statement cache size), JVM tuning (garbage collection/heap size) and more. These are just a few of the biggies that I run across in my travels that you should consider, there is obviously more. We touch on all of this in the Hibernate 3 advanced training (except for the DB2 stuff) which JBoss and our partners offer.


Hani Suleiman of the infamous bile blog has been elected to the Java Community Process (JCP) Executive Committee (EC). The JCP is the somewhat controversial organization set up by Sun to control, develop and set the standards around Java. Hani's election has come at the expense of Iona. You have probably heard of Iona. They created one of the world's most widely deployed CORBA solutions.


JCP EC member Hani Suleiman:


Let's look at the other luminaries who support this travesty shall we? We have Bob McWhirter (codehaus lead masturbator), Jon Tirsen (incoherent immature loudmouth), hardcore groovy hackers (gosh, they suppport it? Astounding), Geir Magnusson Jr (nice guy, velocity guy, apache minion), and ThoughtWorks (obnoxious pretentious gits). Put together, this bunch of misfits are responsible for a surprisingly huge number of truly horrific ideas. All they need is the Midas touch of Craig Mcflafla to have that ultimate java winning team.


Who is Hani Suleiman? There is a good chance that many people who read this blog are not regular blog enthusiasts. Hani runs a blog called "The Bile Blog" which is predominantly devoted to disparaging Java technologies and vendors with various colorful metaphors which frequently involve comparisons to bowel movements or sex acts. Hani works for a company called Formicary which you have probably also never heard of. I haven't bothered to figure out what they do since the only reason I know who they are is because that is who Hani "that Bile guy" works for.


JCP EC member Hani Suleiman:


I mean, it's one thing to come up with new scripting language and proclaim it to be the best thing since internet porn. In that same vein, even the breathtaking audacity of trying to whore it via the auspices of the JCP can be dismissed as a severe case of mass insanity. However, to do all that AND hijack a perfectly legitimate word is beyond the pale.


Just think of all the poor bastards everywhere who think that they can enrich their lives and maybe even make a bit of money by learning java. They pick up the basics. They pick the clique they want to be part of, they start a blog and unwrap their disused genitalia and prepare for a good few years of furious and misguided tugging. After all that, what do they find? Well, they'll find that doing all that means a reduction in their vocabulary. They will have a word cruelly stolen from them. They will gnash their teeth and tear at their hair when they realise that if they ever want to say 'groovy' again, it had better be yet another hilarious joke about James Strachan's latest illegitimate offspring freakshow. No longer will they be able to casually express approval by using that word, or even exclaim with slight surprise using that particular combination of letters.


Hani will probably truly find it ingratiating that he has been voted onto the JCP (right before biling it), but many will probably read through this for what it is. It is a negative gesture, representing the triumph of mediocrity. Hani's blog is a guilty pleasure for many of us, but has the "Java community" become so decadent that scribbling obscenities on the public toilet walls of the Internet is now considered a meaningful "statement"? Hani has managed to get himself elected to a number of JCP committees where he mostly contributes "why bother" type statements. Is it no longer necessary to establish yourself as a software developer and leader when you can go further by insulting those who do? In addition, Hani prefers to attack the people who "do" rather than their actual work. After all, why limit yourself to criticizing the software when it is so much more fun to insult its authors and consumers....and their children.


JCP EC member Hani Suleiman:


The ridiculous assumptions made by all these articles are breathtaking. It's telling that all these evangelists have next to nothing to do with Java, and are more often than not linux zealots running out of linux stories to masturbate to. For example, the furious arm waving proclaiming that if Java doesn't go opensource, dotnot will win. Absolutely amazing the way this argument can actually be delivered without a hint of humour or sarcasm. Am I the only person who fails to see the Mel Gibsonesque leaps of Faith required to link the two? I mean really, what Java developers are being lost to dotnot? I'll tell you, it's the idiot kids who have that shiteating grin plastered on their faces at the sight of anything new. As soon as it becomes a serious technology, they jump ship and move onto something more hackworthy, or start a codehaus project or something.


If this is the kind of leadership that we're going to come to expect from the JCP, then the validity of the JCP itself comes into question. Sure Sun throws it birthday parties in which representatives of the Klingon Empire attend and claims "JCP. Better than Open Source?" (actual name of a Java One session before I complained; it was also implied at the aforementioned JCP birthday party held during ApacheCon, much to the chagrin of the attendees) -- but is Hani really going to contribute to the design or standardization of Java? He serves a purpose in calling out the excesses and inadequacies of Java and its community, ridiculing its pettiness and self-importance, but nowhere has he demonstrated the qualities necessary to lead this thing? In all likelihood, Hani probably will help Sun spread the fragmented love/hate message about open source:


JCP EC member Hani Suleiman:


What's even more offensive is how various Java type people will actually talk about the idea as if it's a serious suggestion, or a matter worthy of discussion. The sheer presumptuousness of the premise beggars belief. Believe it or not, Java was never about sucking up to a bunch of slashdot teenagers. Who the hell cares what the Open Source Community think of Java? Their goodwill (or lack of, in fact) clearly has had absolutely no effect on Java. Just look at all the Java projects on sourceforge and freshmeat. Not exactly a lonely group desperate for all the marketing it can get.


I'm curious, what contributions do you think Hani will make? New APIs? (javax.insult.AssHat) Extra points for funny.


UPDATE: You can still read the comments here, but they have been disabled because some freak show started posting a bunch of racist hate speech that I found offensive (those posts were deleted). Participants who wish to have a meaningful conversation regarding this are welcome to email me personally, but I have no patience for the type of communication that this anonymous poster espoused. I totally support your right to free speech even the offensive stuff, just not from a server/software that I manage (and I don't support your right to do so anonyously -- you should have to stand by your message).