|
|
optimize Castor transactions by avoiding to re-open JDBC sessions |
Query page
Enter new bug
Currently Castor closes JDBC connections at the end of each transaction, and
creates another session for each following transaction. This is very time
consuming (if not using connection pooling) and might be avoidable when
optimizing the Castor behaviour regarding transactions and JDBC sessions.
Don't closing JDBC sessions at every transaction end can enhance the overall
performanc greatly.
For a illustration of my idea please see this link:
http://www.sky.franken.de/castor/multiple-en.html
------- Additional Comment
#1 From
Martin Fuchs
2005-01-04 06:21 -------
Created an attachment (id=842)
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?
------- Additional Comment
#2 From
Werner Guttmann
2005-01-06 12:44 -------
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).
------- Additional Comment
#3 From
Martin Fuchs
2005-01-07 05:05 -------
Yes, reading bugs 1491 and 1624 it seems to me, I tapped into a wasp's nest with
this bug. ;-)
------- Additional Comment
#4 From
Stein M. Hugubakken
2005-01-07 05:21 -------
I've been thinking of making the transactioncontext plugin-based, that way it's
better to add work-arounds for different databases.
------- Additional Comment
#5 From
Stein M. Hugubakken
2005-01-07 05:23 -------
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 :-)
------- Additional Comment
#6 From
Martin Fuchs
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 ?
Yes, this would make the code clearer.
> If you type bug and number, bugzilla will create a hyperlink automagically :-)
Bugzilla should learn more correct grammatics and also understand "bugs". ;-)
------- Additional Comment
#7 From
Stein M. Hugubakken
2005-01-07 05:53 -------
> ------- 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...
------- Additional Comment
#8 From
Werner Guttmann
2005-01-10 03:24 -------
> Something in that direction...
Plus more .. ;-). I think this will be one of the first areas we should revisit
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 .. ;-)) is that the current TransactionContext/-Impl business
should be replaced with an interface/implementation business, making code
stricter, shorter and more concise.
Query page
Enter new bug
This is Bugzilla: the Mozilla bug system. For more
information about what Bugzilla is and what it can do, see
bugzilla.org.
|
|