Re: Submittal for JDBC Pooling driver (For 7.3)

--- Kov�cs_P�ter <peter.kovacs@sysdata.siemens.hu> wrote:
> Did I say optional pool implementation? Sorry, I did not mean it. I do
> not remember the spec talking about optional pool implementation [in the
> ConnectionPoolDataSource or PooledConnection interfaces] either. The
> pool implementation (according to the spec) belongs to the middleware.

Yes, I can agree that the spec dictates that the core JDBC driver provides
hooks for pooling implementation, not implementation of the pooling
manager itself.

...

> page 29 and page 31). I understand that you need pooling, but based on
> the spec, the right approach (IMHO) would be to implement pooling in a
> package

Sure, I have no problem moving the pooling manager to its own package.
How about org.postgresql.pool?  (Middleware as a package name is abit
ugly to me, but that's just me. ;-)

As I mentioned before, we have two issues. Pooling 'out-of-the-box'
and testing the pooling 'hooks'.  We currently have neither.  Also, I
think
the API into the current code base is broken, but until I get a test-case
around it, I won't know.  I figure I'd submit a pooling manager to start
that test case.

> Are you sure that the Tyrex is the same is as the xa package in the
> postgresql source tree? Maybe is it completely different. Maybe it is
> our xa package + some pooling (->middleware) and just the pooling part
is
> not well implemented. I would think twice before I throw away something,

> because someone said something about something else.

I'm abit confused by what you're saying. Yes, the postgresql xa package
was written by exoffice (now intalio) folks.   When you say above
"+ some pooling (->middleware)" what are you specifically refering to?
If you are refering to the ConnectionPoolDataSource as implemented in
the class org.postgresql.xa.XADataSourceImpl, then yes. I think that
part may be buggy.  But no, I'm not planning to throw anything away.
My submittal was to get comments about functionality for the pool
manager.  But if anything, I want to end up augmenting the cvs code in the

repostiory that was submitted by Assaf Arkin. Its likely my fault for not
making that clear.  I first want to get the pool functionaliy, then see
what to integrate with.  That may not be the best approach, but it was the

easiest approach for me.

(I refer to Tyrex since Arkin worked on tyrex and the postgres xa.  When
you talk about Exoffice, tyrex comes to mind since it would be the first
project to make use of the postgres xa package.)

> The Exoffice xa  package very
> elegantly implements a very complicated functionality (with the added
> complexity that the package integrates RDBMSs with limited transactional
> capability).

I thought it just mimicks a two-phase commit at best, and provides some
of the hooks for the pooling side.  Can you comment more on how the xa
package in the source tree helps with this?  To be honest, it confuses me
since the database doesn't support two-phase commits. (Perhaps we should
be
asking Arkin.)

> When I last seriously looked at JBoss, you could not even use applets
> with their EJB container. Then a few month later I saw something in
their

I'm not following what you mean here.  Do you mean servlets? Like Tomcat?
That are integrated with Tomcat now, but I prefer having a different
process space to run my EJB server than my Tomcat server.

> docs to
> this effect, but they surely did not support message protection (over

Do you mean JMS?  Sorry, but I'm confused on what your saying.  Can you
be more specific?

> applets). Now I cannot even check, because you have to buy the docs.

Check out http://www.jboss.org/online-manual/HTML/index.html for their
docs onine. They are up-to-date for 3.0

> (You can download the sources, though, and find yourself the answer.)
> They want
> to stick to the EJB, but to use this trade mark will cost them lots of
> money, so their already started to become commercial. And if they want
> to keep going they will end up concluding Sun Source Code Lincense
> Agreements and that will definitely bar them from remaining open source,

> like Lutris went close source a few months ago for similar reasons.

No, that's not their plan.  They are providing hard-copies of docs for
cash, yes. PostgreSQL does that too.  But they've been pretty much
against charging for their product.  See their comments at
http://www.jboss.org/vision.jsp for more specific info.  Also, check out
their http://www.jboss.org/licensesun.jsp for their license issues and
a comparison to lutris.

> OK. I rest my case. (And let you rest yours :-)). Let's take some rest.

Rest is good. :-)  I'll make an update to my submittal placing a specific
pooling manager in a different package as you suggested.  I'll see if I
can use the XA connections that Arkin wrote as effectively as my own.
(Likely better, Arkin's got some good stuff. :-) and if it works, I'll
submit it to the group.  I won't submit patches against the XA classes
yet, since I'm not ready for that.

Does anyone else have thoughts on the pooling side that I've been working
on?


=====
Virtually,        |                   "Must you shout too?"
Ned Wolpert       |                                  -Dante
wolpert@yahoo.com |
_________________/              "Who watches the watchmen?"
4e75                                       -Juvenal, 120 AD

-- Place your commercial here --                      fnord

__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com