Bugzilla Version 2.16.7
Bugzilla Bug 1843
  optimize Castor transactions by avoiding to re-open JDBC sessions
     Query page      Enter new bug
Bug#: 1843   Platform:   Reporter: martin-fuchs at gmx dot net (Martin Fuchs)
Product:   OS:   Add CC:
Component:   Version:   CC:
Remove selected CCs
Status: NEW   Priority:  
Resolution:   Severity:  
Assigned To: ferret at frii dot com (Bruce Snyder)   Target Milestone:  
URL:
Summary:

Attachment Type Modified Status Actions
first version of a patch patch 2005-01-04 06:21 none Edit
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 1843 depends on: Show dependency tree
Show dependency graph
Bug 1843 blocks:
Votes: 0    Show votes for this bug    Vote for this bug

Additional Comments:


Leave as NEW 
Accept bug (change status to ASSIGNED)
Resolve bug, changing resolution to
Resolve bug, mark it as duplicate of bug #
Reassign bug to
Reassign bug to owner of selected component

View Bug Activity   |   Format For Printing

Description: Opened: 2005-01-02 08:56

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.
Actions: New | Query | bug # | Reports   New Account | Log In