I really like Open Source software. I use it a lot: Linux, apache, postfix, amavis-new, clamav, openSSL, openLDAP, PostgreSQL, PHP are just a few of the OSS products I have on my servers.
When developing JAVA, I use Eclipse, Ant, JUnit and heck even Java 🙂
OSS is actually very important for be, being a Freelance I/T consultant, it allows me to play with features, technologies and implementations, in an effective manner, without having to pay a lot in license fees!
I’m not a big committer. Not that I don’t want to, but usually when I hit a bug or a poorly implemented feature, I either accept it or code around it.
Only 3 times since I started using OSS for the first time in about 2002 have I been in a situation where I had something to contribute with:
- Some missing Locale handling in Struts. I was just about to submit a patch when I discovered someone else had done just that a few days before.
- A bug in Stripes – also related to Locales – rendering some of the features useless if the Locale does not contain a valid country code. This was somewhat accepted by Tim Fennel and made it into version 1.4.
- A serious performance problem in Hibernates WebSphere transaction adaptor. This I fixed and submitted as a patch and then the story being told here is about to begin.
Apart from that, I try to contribute with helpful comments when I see someone report a problem I’ve seen and possibly solved myself. At least to let the other users know there are others with the same problem.
Does it make me a bad person? I think not – I’m no more different than 99.99% of all other OSS users.
This blog entry (or article) is meant as a warning to anyone who considers making a contribution to a major open source product.
The conclusion
To start with the conclusion – here’s what I’ve learnt from trying to “do the right thing” and submit a patch to an OS project:
- Don’t expect to be treated with any respect at all, unless you are already a known committer – “one of the guys”.
- If you do commit anything, expect that you are to be considered the maintainer of the feature from that point on.
- Expect to have your name and personal email specified as author of source and comments that you have not written.
- Be aware that when you submit anything, the project owner can do with it as he pleases; even break the implementation, and still call the bug fixed…
- Be aware, that if you do not agree with the King of the project, he can call you anything he likes, telling that you are being spiteful and things that are worse.
JPA
Now, I was assigned to this interesting project. My first task was to rewrite the entire persistence layer from EJB 2.1 CMP to JPA. J2EE Application server was WebSphere version 6.1 (WAS).
After an initial discussion, the lead architect and I decided we would go with the Hibernate-JPA implementation. I developed a small PoC that demonstrated we could persist some of the important business entities and that the JPA implementation could integrate with the WebSphere transaction manager. Everything looked good and we proceeded.
After about one week of “hard coding” I ran the first small test suite and was quite happy to realize the entire suite passed without a single error!
I showed it to the lead architect and he had one comment: “Yes, they all pass. But they are slow!”
The tests in the suite would normally run in 100-200ms each. With the Hibernate JPA implementation, they took about 1-2 seconds each to run! This was effectively a showstopper…
The lead architect and I sat down and discussed different options. But we really had no short-term solutions – we kind of had to use Hibernate-JPA or wait for IBM WebSphere to deliver a “real” JEE 5 compliant EJB container…
So I was allowed to spend some time trying to figure out why Hibernate-JPA was so slow and eventually come up with a fix.
Now, there were a lot of strange log messages in the server log. They all indicated the creation of an InitialContext with no properties. As if something is looked up in JNDI all the time. Looking at the log, I could see the messages were from a NamingHelper class. I added a stack trace to the logging in the NamingHelper, so I could see from where it was called: all except one originated from the WebSphereExtendedJTATransactionLookup class!
It showed that in the Hibernate core version 3.2.3, an initial context creation and a lookup of the WebSphere proprietary “extendedJTATransaction” object was done each time a TransactionAdapter was created, which in turn is done each time the getTransaction() method was called on the TransactionManagerAdapter…
This again amounts to 4 times during EntityManager creation, one for each non-trivial call into the EntityManager instance and one when the transaction is about to end – (5 + n) for each transaction, n being the number of non-trivial EM calls during the transaction.
This is the reason why it performed badly!
OpenJPA
We had been looking into OpenJPA but had discarded it for a number of reasons. But as far as we knew, the IBM JPA feature pack for WAS is based on OpenJPA and there is an IBM developerWorks article describing how to use OpenJPA with WAS.
One of the authors of this article (Kevin Sutter, Senior Software Engineer, IBM) is also one of the authors of the WASManagedRuntime – the OpenJPA implementation similar to the Hibernate WebSphereExtendedJTATransactionLookup.
In the WASManagedRuntime, the WebSphere proprietary “extendedJTATransaction” object is only looked up once, during “configuration” and stored as an instance variable. As the WASManagedRuntime instance is a static in another class, it means the “extendedJTATransaction” object is effectively stored in a static!
I then hacked the Hibernate core version 3.2.3 of the WebSphereExtendedJTATransactionLookup implementation to only lookup the “extendedJTATransaction” object once and then store it in a static.
Now the test suite passed, the PoC was still working, and performance was equal to the EJB 2.1 CMP implementation!
The patch
Now, happy with myself, I decided that it would make sense to contribute to Hibernate core – I believed my patch would be helpful…
I read the instructions in READ THIS BEFORE USING JIRA. Trying to follow procedures, I searched the user forum and JIRA for anyone reporting a similar problem. I found one entry in the user forums Performance prob many JNDI-lookups to Websphere transaction and nothing directly related in JIRA.
Nobody had posted a reply to the entry in the user forum, so I decided to subscribe to the developer mailing list and discuss my patch there.
My message to the developer mailing list (Note: I had 2 points, only the first one is relevant here):
Hello,
just trying to follow the guidelines in the section "READ THIS BEFORE
USING JIRA!", I'm submitting minor changes to the classes
WebSphereExtendedJTATransactionLookup and FromClause for anyone to
review.
1. We are using Hibernate JPA with WebSphere 6.1 and are experiencing
serious bad performance. We are also seeing alot of "INFO
org.hibernate.util.NamingHelper.JNDI InitialContext properties:{}" in
the logs (as described in
http://forum.hibernate.org/viewtopic.php?t=970086).
Our investigations shows that the logging statements come from
NamingHelper.getInitialContext().
Also, we can se that just creating an EntityManager from an
EntitManagerFactory results in 4 times InitialContext creation and 4
times lookup of the WAS specific
"java:comp/websphere/ExtendedJTATransaction".
A simple transaction results in 7-8 lookups !
By looking at a similar implementation in OpenJPA's
(openjpa-0.9.6-incubating) AutomaticManagedRuntime /
WASManagedRuntime, it appears that OpenJPA only looks up the
"extended transaction" object once, and stores it in a static.
I've changed the WebSphereExtendedJTATransactionLookup so the
innerclass TransactionAdapter ctor does the lookup and stores the
extendedJTATransaction in a static in the
WebSphereExtendedJTATransactionLookup class.
This solves our performance problems.
Now, the WebSphereExtendedJTATransactionLookup class is not heavily
documented (...) so it is not obvious to us if this breaks something
else.
This started a nice and civilised conversation with Max Rydahl Andersen about the nature of the “extendedJTATransaction” object, and whether it was safe to store it in a global variable (a static).
We agreed that if the object was made instance of the WebSphereExtendedJTATransactionLookup class, that would ensure only one “extendedJTATransaction” object would be looked up for each EntityManagerFactory.
I changed my implementation, tested it and submitted it as a patch to Hibernate core 3.2.3 (http://opensource.atlassian.com/projects/hibernate/browse/HHH-2580). I demonstrated with excerpts from the logs that the patch did a tremendous difference.
Max commented kindly about me appending logs as comments and told me I should use attachments in the future, and had a comment that he would like to hear from Steve about the patch. Steve here is Mr. Steven Ebersole.
I was thrilled to experience that the patch was accepted and was targeted for inclusion in Hibernate core version 3.2.4.
This was April 19, 2007.
Almost 3 weeks later
On May 8, 2007 things start to change, fast.
Suddenly Mr. Ebersole decides the patch needs a rewrite before it can make it into the 3.2.4 version. Mr. Ebersole basically breaks the patch, reintroducing the performance problem. And he closes the patch as being “fixed”.
Via comments in JIRA I tried to tell Mr. Ebersole that his implementation reintroduced the performance problem; and I tried to tell him why I had chosen the original implementation (http://opensource.atlassian.com/projects/hibernate/browse/HHH-2580#action_26879).
Somehow this really pissed Mr. Ebersole off. I have no idea why – he only has some rather general ranting about WAS and tells me he prefers “correctness over performance”. Only if I can show him some resource stating my implementation is correct is he going to accept it. Somehow it is not enough for him that it is similar to the implementation in OpenJPA – or maybe Mr. Ebersole is just not paying attention.
And he asks me to take over maintenance! This I take as either sarcasm or him being bitter…
In my next comment (now I’m pissed) I tell Mr. Ebersole that I think his implementation sucks (it did), I demonstrate that I have actually tested it and prove that 4 initial context creates and lookups are still being performed when an EntityManager is being created.
Mr. Ebersoles sole reply is: “Ok, we’re done”.
The 3-day mail tirade
Now I start my email campaign: I write 3 different emails to 3 different IBM’ers that I think can help on the subject, I write Max to ask him if he knows what is going on. And I write the following to Mr. Ebersole:
--------------------------------------------------------------------------
Subject: Re: (HHH-2580) Performace: Too many lookups of WAS extended transaction support (Jesper Udby) From: "Jesper Udby" Date: Tue, May 8, 2007 16:17 To: "Steve Ebersole" <steve@hibernate.org>
--------------------------------------------------------------------------
Excuuuse me, what did I do to piss You off this way ? I was actually trying to help... Maybe I should create a new issue regarding the problem that the Hibernate core implementation want's to create 4 seperate instances of the TransactionAdapter just creating an EntityManager (you _could_ take a look at the stacktraces I provided), then yet another one for each call into the EntityManager and then one when the transaction is about to end ? Seriously, that is something "somebody" should look into ? Just stating that You prefer "correcness over performance" is not the most wise statement, when You actually do not know what is correct - according to the not very well documented IBM proprietary API... Rgds Jesper Udby > > [ > ... > ] > > Steve Ebersole kommenteret på HHH-2580: > ------------------------------------- > > Ok, we're done > ...
He did not take that lightly – here is his reply:
--------------------------------------------------------------------------
Subject: Re: (HHH-2580) Performace: Too many lookups of WAS extended transaction support (Jesper Udby) From: "Steve Ebersole" <steve@hibernate.org> Sender: "Steve Ebersole" <steven.ebersole@gmail.com> Date: Tue, May 8, 2007 17:09 To: "Jesper Udby"
--------------------------------------------------------------------------
First, I have never used WAS. I plan to never use WAS. I think it is a piece of garbage. And I hate that they make something difficult that is trivial in every other app server. Then they claim that this is "to protect their customers" from themselves. This is fucking bullshit, since they then turn around and expose the same exact functionality via proprietary APIs. What they are trying to protect is their license revenue. I am extremely happy that JEE5 makes this required functionality to be exposed for a compliant app server. IBM will finally have to stop playing this silly, silly game they play. Second, calling someone else's work "crap" is not helping; its called being spiteful. I don't help spiteful people. This is not even anything I wrote, so trust me this is not personal protection and anger over "my code". This has more to do with decency and respecting the fact that you are using people's work that they have let you use without even paying them a dime. Third, the change I made should limit the JNDI lookup to one per EM instance. Have you even bothered trying it? Fourth, yes somebody should look into it. You know who? YOU! You know why? Because this is something called open source. And this in particular is something in which you obviously have a vested interest. That is the whole idea behind open source. Fifth, don't lecture me about "wise things" to say. Obviously doing a lookup each time is always going to give "correct" results. Don't be silly; think about something before you speak it.
Now, I’m not allowed to say about his questionable implementation that it “sucks”, but he is allowed to call WAS garbage, using words like “fucking bullshit”, say ‘ve called someone else’s work “crap” (I didn’t), questions if I’ve tested his implementation (he obviously have not – I actually had) and he calls me spiteful.
My God, he must have a bad day! This answer is so filled with anger that I can hardly believe it! And I honestly was a little surprised he even bothered to answer. I had to try some Danish sarcasm on him, just to see if he was for real:
--------------------------------------------------------------------------
Subject: Re: (HHH-2580) Performace: Too many lookups of WAS extended transaction support (Jesper Udby) From: "Jesper Udby" Date: Tue, May 8, 2007 19:44 To: "Steve Ebersole" <steve@hibernate.org>
--------------------------------------------------------------------------
Thanx for answering my mail. 1. Some major customers seem to prefer IBM products for whatever reason. You may call it garbage b/c it is something some customers pay $$$ for ? For some of us this is just the reality we work in - and we have to live with it. But then again, I do earn good money working with this garbage... I can say I will never ever work with WAS or other garbage IBM products - and loose most of my customers... 2. I don't remember calling someone else's work "crap". I said your implementation sucks. Sorry for that - I was only focusing on the implementation in the WebSphereExtendedJTATransactionLookup source file... (If you take a look at the ctor of the TransactionAdapter inner class, You will have to agree that the "null" checking of the instance variable and the "lazy instantiation" does look a bit strange, being in the ctor...) 3. Yes, I tested the change... The (partial) stacktraces I added in the comment was meant as documentation of how many times the TransactionAdapter was instantiated - all within the same transaction. I did that by inserting a "new Exception().printStackTrace()" in the ctor just beneath the lookup... I was only focusing on the WebSphereExtendedJTATransactionLookup implementation. You mention you've made changes that limit the lookup to on per EM instance - then you must have changed other files as well. I will look into that tomorrow when I'm back at my customer. 4. I did look into it some time ago. But, being paid by the hour by my customer, there are limits to how many hours I can spend trying to dig into the Hibernate core implementation. So I made a patch (my customer paid for that as well) and submitted it, hoping the performance problem would be solved in an upcoming release. I'm sorry, I work as a prostitute in JEE land. This is ok, but my spare time is rare, so I do not normally spend time digging into things unless it pays back (to me) somehow. Sorry for that. 5. Doing (create initial context +) lookup each time you need something might always give "correct results" but is not necessarily the "correct" way to do it... Or am I completely wrong here ? And last: If you hate WAS and IBM so much (being a former IBM'er I don't actually fancy neither too much myself), why do you even care this much about the WebSphereExtendedJTATransactionLookup implementation ?? If the patch some stupid freelancer submits fixes a major performance problem, then why even bother bullying the poor guy this way ? Why change it to something else when you cannot even test your change ? Is this a good way to do software development ? Then again, thank you for working for free for me and all the other happy Hibernate users out there. And sorry for my English - it is not my native language. There might slip some unintentional bad language in. Rgds Jesper Udby
Not too bad? But I mean every single word of it! In my book it is generally good practice to cache stuff looked up in JNDI for as long as it makes sense…
Now, Mr. Ebersole didn’t resist this one either, and had the following angry reply – he just has to read my writing as Someone else reads the Bible:
--------------------------------------------------------------------------
Subject: Re: (HHH-2580) Performace: Too many lookups of WAS extended transaction support (Jesper Udby) From: "Steve Ebersole" <steve@hibernate.org> Sender: "Steve Ebersole" <steven.ebersole@gmail.com> Date: Tue, May 8, 2007 20:28 To: "Jesper Udby"
--------------------------------------------------------------------------
> And last: If you hate WAS and IBM so much (being a former IBM'er I don't > actually fancy neither too much myself), why do you even care this much > about the WebSphereExtendedJTATransactionLookup implementation ?? > If the patch some stupid freelancer submits fixes a major performance > problem, then why even bother bullying the poor guy this way ? > Whether or not I hate IBM has nothing to do with this issue. Every so often someone comes along and requests a change to either WebSphereExtendedJTATransactionLookup or to WebSphereTransactionManagerLookup. And the change "seems" reasonable; but we add it and it breaks someone else using Hibernate+WebSphere. So I am done making ad-hoc changes to either of these classes until someone is willing to be accountable for integration with WebSphere (which is comprised of just these two classes). Someone out there has a vested interest in having these two work together (as evidenced by your people "prefering" WAS) and willing to lend a hand. Until then, I refuse to make any more of these changes. > Why change it to something else when you cannot even test your change ? > Is this a good way to do software development ? > I can generalize that performing a contextual lookup *more often* will generally give correct results. Again, don't be silly. This and your previous comment about "wise statements" simply show that you are not thinking these questions through. I'll give you the benefit of the doubt that you are not being spiteful. Also, you question me about good software development process; is a good process to leave integration development to someone who (a) does not know the product being integrated and (b) could not care less about the integrated product? BTW, you realize that this is a defined extension point of Hibernate, right? If you don't like the provided implementation then supply your own, custom one.
Ok, he’s totally out of reach. But his last comment did give me a great idea. I repackaged my patch to fit the project structure and reconfigured the Hibernate solution to use my implementation. Tested it and agreed with the lead architect that this would do until IBM can provide a true JEE 5 compliant EJB container or perhaps a future switch to another application server vendor.
But, one thing bothered me: I didn’t knew the Danish word for spiteful, and Mr. Ebersole still indirectly implies that I am being spiteful… Looked it up and got very surprised! So, trying to help makes me SPITEFUL?!! Reading the past email conversation with Mr. Ebersole certainly makes him spiteful, in my optics.
In the meantime, I had a conversation with one of the 3 IBM’ers. He basically confirms that it is ok to cache the “extendedJTATransaction” instance, but he also tells me that I cannot quote him on this. Bugger – would have been a nice message to give…
I just had to try Mr. Ebersole again – but this time I was seriously pissed of, not trying to hide my sarcasm – and I try to give the message without quoting anyone in particular:
--------------------------------------------------------------------------
Subject: Re: (HHH-2580) Performace: Too many lookups of WAS extended transaction support (Jesper Udby) From: "Jesper Udby" Date: Wed, May 9, 2007 09:42 To: "Steve Ebersole" <steve@hibernate.org> Cc: "Max Rydahl Andersen"
--------------------------------------------------------------------------
Hello Steven. > > BTW, you realize that this is a defined extension point of Hibernate, > right? If you don't like the provided implementation then supply your > own, custom one. > What a great idea - I've done just that and it works nicely. It does not improve the quality of the Hibernate core implementation, but what do I care: It is only a matter of time before I work in a JEE 5 compliant container... .. Now, I've taken the libery to look up the word "spiteful" in an English -> Danish dictionary and I'm kind of surprised that you call _me_ spiteful ?! I will try to repeat the sequence of events from my point of view, just trying to proove that I'm certainly not even trying to be spiteful. Please take the time to read the entire mail... * On a medium sized J2EE project, the persistence layer was converted from CMP EJB 2.1 to JPA. The Hibernate implemetation was chosen because it seemed to be the most mature implementation and could integrate with WAS' CMT... * Running the first few testcases showed serious performance problems: simple transactions normally in the 100-200ms range now took 1-2s with the Hibernate JPA implementation. This is basically a showstopper for the project. * I searched the Hibernate user forums and JIRA for anyone with similar problems and found one post: http://forum.hibernate.org/viewtopic.php?t=970086 * Noone had answered the post and no bugs was reported so we decided to look at other persistence providers. OpenJPA was chosen as a candidate, as IBM's "EJB3 feature pack" for WAS is based on OpenJPA. * For a number of reasons, OpenJPA (or the feature pack) was not a possible short-term solution. * I was allowed - by the project lead architect - to spend some time trying to figure out if we could fix Hibernate in some way. * I found the performance problems was related to the (5+n)/tx lookups of the WAS' extended JTA support instance for each EM created in the tx - n being the number of non-trivial EM method calls in the tx. In the similar OpenJPA implementation (WASManagedRuntime), the extended JTA support instance is basically look'ed up once and stored in the WASManagedRuntime. As the WASManagedRuntime instance again is a static in another class, this is effectively the same as storing the extended JTA support instance in a static... * In order to try to follow procedures (and trying very hard NOT to be spiteful), I joined the hibernate-dev mailing list and started a conversation with Max about the issue. * Max does not like storing this instance in a static and we agree that caching it in the WebSphereExtendedJTATransactionLookup instance would ensure we have only one lookup per EntityManagerFactory. This is ok as creation of the EMF alone takes 8-10s - adding another 100ms is no big deal. * Again, as agreed with Max, I made the change to the WebSphereExtendedJTATransactionLookup, tested it with our project and submitted it as a patch to hibernate. * Now, after some time, Steve comes into the picture, decides that the issue is not a Major issue (well, perhaps not if you don't use WAS, it isn't). Then deciding - w/o even bothering testing - that the implemtation is "not correct" and reimplents it, thereby reintroducing the performance problem and closes the issue as fixed ! * I tried to tell Steve - trying very hard not to sound too bitter - that the reimplemtation basically broke the patch. And, btw, I DID test it before writing the comment in HHH-2580 (http://opensource.atlassian.com/projects/hibernate/browse/HHH-2580#action_26879). * Steve then basically tells me that he prefers "correctness over performance"... * I then take a look at the changed WebSphereExtendedJTATransactionLookup from svn... Now, seriously Steve, if you look at lines 115-117 of (11481) WebSphereExtendedJTATransactionLookup, you will have to admit that the implementation is questionable (testing an instance variable for "null" in a constructor ??). I did not use the C-word, but I did say that your implementation "sucked". And it does. We'd all be better of if you simply rejected the patch - now it has status closed+fixed but it is definately not fixed. ... Now, I've tried very hard to actually being helpfull, submitting "important" changes to improve the performance of Hibernate with WAS CMT. And trying to "follow procedures". Only a twisted mind can see this as being SPITEFUL ! Steve, I think you need a loong vacation or perhaps another job. What you are currently doing is to upset people who are seriously trying to help the OSS efforts of Hibernate. A man in you position should do the exact opposite. I don't believe I've given you any reason whatsoever to question my motives for "trying to help". You, on the other hand, behaves like a little Queen, having her period or a couple of bad hair days, bullying everyone that does not have the right opinions. Please step down from your throne and try to see things from a more constructive perspective - letting the arrogance and ignorance stay on the top of the throne. ... I've had a very interesting conversation last night with --beep-- --beep-- --beep-- --beep-- --beep-- --beep-- --beep--. He basically tells me it is ok to store the extended JTA support instance in a static. Ufortunately, he does not allow me to quote him on this - pointing me in the general direction of OpenJPA and WebSphere support... So, NOW we are done. I couldn't care less about the quality of Hibernate core. I've not used it in the past and I'm definately not going to try to fix anything else in it in the future (this probably makes you happy). Bye and thanks for showing me how big EGO's these OSS project lead's can be :-> /Udby
I put Max Rydahl on CC as he had shown an interest before, and he has actually been very helpful. Being a colleague to Mr. Ebersole, he might be able to persuade him into stop being such a bitter, angry man…
But, Mr. Ebersole did not resist this one either:
--------------------------------------------------------------------------
Subject: Re: (HHH-2580) Performace: Too many lookups of WAS extended transaction support (Jesper Udby) From: "Steve Ebersole" <steve@hibernate.org> Sender: "Steve Ebersole" <steven.ebersole@gmail.com> Date: Wed, May 9, 2007 14:26 To: "Jesper Udby" Cc: "Max Rydahl Andersen"
--------------------------------------------------------------------------
Here's the sequence of events from my point of view: * For well over 2 years now I have written code that you and many many others use without giving me anything in return. * During that time, integrating with WAS JTA "support" has been nothing but a pain in the ass. People come along every so often and suggest some change. More often then not their suggested change breaks other people's usage. That's an indictment on how crappy WAS JTA support is, not the users suggestions per-se. But regardless, here I am trying to figure out what the RightThingToDo is based on non-existent (public) documentation and zero experience with the product. Yet none of these users want to take ownership of the integration, or even their suggested changes. Really, they just want me to take over up-keep something that happened to work for them so they don't have to manage it with new Hibernate releases. * Along comes Jesper in the same vein described above, with his suggested change. Does he want to own it or the integration? No! Can he point me at documentation or resources stating that his suggestion is valid? No! Can he at the very least assuage my concerns and verify that this is valid usage? No! How about at least be civil with regards to people who have allowed him unfettered use of their blood, sweat and tears? No! Instead he'd rather launch into a 3-day email tirade. Well at least at the end of the 3-day tirade you did verify that the suggested scoping works. I'll change it back to what you initially proposed. And yes, saying someone's work "sucks" and being generally non-civil is being spiteful. And please don't lecture me about how OSS works or my attitude. I've done OSS work for 3 years now; how about you? One patch does not give you the right to lecture me. Trust me, my life is perfectly pleasant before you; and it'll be perfectly pleasant after you go away. I have a big ego?!?! LOL! That's fucking hilarious. A big ego is lecturing me about how I should run a project you use for free. *NOW* we are done.
Right, now we are getting somewhere:
- People come along and suggest changes to the WAS JTA integration, that breaks others usage (search JIRA and go figure – it ain’t happening or Hibernate does not want them documented).
- Integrating with WAS JTA “support” is a pain in the ass. WAS JTA support is crappy. Nice wording again Mr. Ebersole.
- Non-existent documentation? Googling e.g. “java:comp/websphere/ExtendedJTATransaction” gives as first hit a link into public IBM documentation, even with JavaDocs. And, one only have to look in OpenJPA for a sample implementation – done by at least one IBM’er…
- If “people who come along” mean business, they are supposed to take over the integration (yeah, right).
- Mr. Ebersole has done 3 years of OSS work now – this entitles him to use bad language against all us ignorant non-OSS workers? One patch does not give me right to lecture him. What if I had done 5 or 10 patches? Who, actually, are allowed to lecture Mr. Ebersole?
- 3-day email tirade. Now, if Mr. Ebersole would stop pouring out bile each and every time I email him, it would never had gone this far. And a little under 18 hours hardly makes it 3 days… If I were a paying customer of this product, I would have demanded to talk to Mr. Ebersoles Boss after his first bile outburst.
- Somehow Mr. Ebersole got the message – he had turned 180 degrees and decided to use my initial implementation. Now, should I laugh or cry?
Then, suddenly, a few hours later I receive the following surprising email form Mr. Ebersole:
--------------------------------------------------------------------------
Subject: Re: (HHH-2580) Performace: Too many lookups of WAS extended transaction support (Jesper Udby) From: "Steve Ebersole" <steven.ebersole@gmail.com> Date: Wed, May 9, 2007 16:52 To: "Jesper Udby" Cc: "Max Rydahl Andersen"
--------------------------------------------------------------------------
Forgot to mention that I made certain to give you deserved credit for your work on WebSphereExtendedJTATransactionLookup: /** * TransactionManagerLookup implementation intended for use with WebSphere * Application Server (WAS). * * WAS, unlike every other app server on the planet, does not allow direct * access to the JTS TransactionManager. Instead, for common transaction- * related tasks users must utilize a proprietary API known as * ExtendedJTATransaction. * * Even more unfortunate, the exact TransactionManagerLookup to use inside of * WAS is highly dependent upon (1) WAS version as well as (2) the WAS * container in which Hibernate will be utilized. * * WebSphereExtendedJTATransactionLookup is reported to work on WAS version 6 * in any of the standard J2EE/JEE component containers. * * @author Gavin King * @author <a href="mailto:xxx" mce_href="mailto:xxx">Jesper Udby<a>
Now, Mr. Ebersole, being King of the Hibernate core implementation, suddenly thinks I should have credit for my work. Yeah, right.
Mr. Ebersoles implementation is not identical to mine, although they are similar and possibly equal in functionality. But, the comment is certainly not mine and I was not asked if it was ok for him to put my name and private email into the source. Saying my private email, the one I’d used with my conversation with him, and not the one I’d specified in my JIRA profile. Now, how professional is that ?
I had had enough. I was fed up with Mr. Ebersoles strange angry and bitter bile. But I was also sorry that the conversation had gotten so much out of hand.
So, I wrote one more email, this one trying to soften things and indicating that I think we should stop the conversion. I also cowardly blocked Mr. Ebersoles known email addresses in my mailserver. I am not going to repeat the mail here. But, somehow Mr. Ebersole had found the email address I’d specified in my JIRA profile, and sent the following to my gmail account:
I am no math genius, but you certainly are a programming genius. Heck, you worked for IBM. They only hire the best and the brightest. I am not the author of the implementation. My name is not Gavin King. Apparently you are not a reading genius either. And I am not cowardly enough to block emails from you. I can take it as well as I dish it out, unlike you. ;) But given your arrogance and belligerent attitude, I am removing you from being a member of our JIRA. BTW, what was that custom number again??? Riiiiiiight... And no, I did not have a lot of free time at Vignette. Just that back then users weren't assholes (yes, you *are*) and there was actually a pretty cool community surrounding Hibernate. Obviously that has since degraded with the coming along of "corporate developers" and folks who are forced to use it instead of wanting to use it such as yourself. Such is life. Yes, now we are done. kthxbye
More bile… And the last sentences I can only interpret one way: Mr. Ebersole is fed up with “corporate developers” and folks forced to use Hibernate. They are generally assholes and are ruining the community. Back in the good old days the community surrounding Hibernate was pretty cool…
He should find himself a new job and a new OS project to be the King of.
And, by the way, if I had a customer number, I would have demanded a serious chat with Mr. Ebersoles boss about his language and manners towards users, committers, possible customers and competitors!
One last thing – I got the following reply from another of my 3 IBM emails sent:
Hi Jesper, I can confirm that WebSphere's ExtendedJTATransaction implementation is a stateless accessor object that needs only to be looked up once and not for each transaction. The most performant use of the class is to look it up once and cache it, exactly as you suggest. Regards, Ian Robinson STSM, WebSphere Transactions Architect IBM Hursley Lab, UK
View Jesper Udby's profile