LOL... that would be an excellent idea, if we weren't an Apache project. Apache is a 501(c)(3) non-profit organization. Although, they could hire us as consultants to do the deploy for a service fee. But then we'd have to get out resumes, and they'd have to hire us.
Maybe I'll just release this weekend for free. :-) Clinton -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Larry Meadors Sent: February-05-08 11:18 AM To: [email protected] Subject: Re: Ibatis throttle - possible deadlock (ibatis 2.2, 2.3) We just need to have an "iBATIS_Release_Bounty" paypal account that people can use to *encourage* more frequent releases. ;-) Larry On Feb 5, 2008 9:24 AM, Clinton Begin <[EMAIL PROTECTED]> wrote: > > > > > Thanks Eric. > > > > If you're seeing issues similar to those Eric describes, also try building > iBATIS from the trunk. It should help draw out the problem because we've > removed the object pools for sessions, requests etc. So where you may have > seen a deadlock before, now you should see a big nasty exception from your > app server that tells you that you've had a connection open too long, or > that you forgot to close a connection. Or perhaps it will hang too, who > knows. :-) > > > > I apologize for not getting a release out yet. It's simply a matter of > finding the time in an insanely busy year already! > > > > I'd suggest holding a vote for which iBATIS developer should do the build, > but I have a feeling I'd win (i.e. lose). ;-) > > > > Cheers, > > Clinton > > > > > > From: Eric Floehr [mailto:[EMAIL PROTECTED] > Sent: February-05-08 8:47 AM > To: [email protected] > Subject: Ibatis throttle - possible deadlock (ibatis 2.2, 2.3) > > > > > > All, > > > > I wanted to let you know my experience with this issue. We saw the same > issues and deadlocks that others have reported, especially under heavy > loads. > > > > As Clinton suggested, we looked to verify we were using the proper > transaction pattern (start, commit, end) in the right try.catch.finally > blocks. It was there that we noticed within the transaction block a bit of > code that took a lot of time to run and did not need to be in the > transaction block. Removing that code to outside the transaction and thus > tightening up the transaction block really helped. Just FYI in case anyone > else is seeing this issue. > > > > Regards, > > Eric > >
