|
|
|
Martin, there's actually a lot of bugs out there that discuss refactoring all
this connection closing business, incl. limitations of the current implementation, reasons why it's done one way or the other, etc. Can you please read up on this ? Having said that, touching any of these methods is serious business, according to Thomas Yip (the author of this code, because of implementation details of various ejb/j2ee web containers). Yes, reading bugs 1491 and 1624 it seems to me, I tapped into a wasp's nest with
this bug. ![]() I've been thinking of making the transactioncontext plugin-based, that way it's
better to add work-arounds for different databases. BTW Martin,
If you type bug and number, bugzilla will create a hyperlink automagically Like bug 1491 and same goes for comments, like comment 1 You are thinking of one class replacing the current TransactionContextImpl with
_globalTx=true and another class replacing TransactionContextImpl with _globalTx=false ? Yes, this would make the code clearer. > If you type bug and number, bugzilla will create a hyperlink automagically > ------- Additional Comments From martin-fuchs at gmx dot net 2005-01-07 05:44 -------
> You are thinking of one class replacing the current TransactionContextImpl with > _globalTx=true and another class replacing TransactionContextImpl with > _globalTx=false ? > Something in that direction... > Something in that direction...
Plus more .. ![]() after the 0.9.6 release, as there's various public and local solutions floating around, and any of those will solve at least two issues related to this discussion. My personal opinion, as stated already elsewhere (read, I cannot remember where .. ![]() should be replaced with an interface/implementation business, making code stricter, shorter and more concise. Martin, re-reading some very old issues, I wonder whether such a feature us really required. I mean, using a connection pool should be straight-forward these days with the availability of e.g. Jakarta Common DBCP, and in such an environment, the performance gain should be ignorable. Please, let me know what you think of this my comment.
I tried to find a way and explain it how Castor could avoid closing and re-opening database sessions. Using a connection pool improves the situation, but my target was to make things as simple as possible and avoid any unnecessary calls outside the library. One year ago you explained my approach is not sufficient, but the issue should be embedded a upcoming TransactionContextImpl rewrite. It seems this did not take place. Well, as I didn't find time and occasion to look further into it, my patch didn't get better. If you think it's not the direction in that Castor should go, then you might deactivate this Jira issue.
Martin, I honestly didn't want to challenge the validity of your suggestion, if that's how my comment came across. If that's what happened, let me please apologize, as that has not been my intention. I agree with you that minimizing external dependencies is by definition a valuable approach. But at the same time, I wonder whether "re-inventing" the wheel in one way or the other is the right approach. And as you have mentioned yourself, we are all limited by time constraints ..
![]() For those using drivers this patch provides a big performance improvement but also for datasources with connection pooling a small improvement may be achived. To me this seams to be a quite simple patch. The only drawback is that the user needs to call db.close() to release connections but he should anyway do this to release other resources. This also sounds to me as a step towards the support of checkpoints which we should support anyway.
Btw, just for completeness, the TransactionContext(Impl) classes have been refactored into an interface (TransactionContext), a base implementation and two separate implementation classes for local and global transactions, all to be found in the org.castor.persist package.
|
first version of a patch
Could please someone with experience about using Castor in a EJB container look
into this patch and test, if also works in this environment?