Обсуждение: Submittal for JDBC Pooling driver (For 7.3)
Folks-
I wasn't going to submit this code until 7.2 was released, but I've
wanted to have it available for folks to examine. I'm hoping to get it
in the 7.3 release. Its a set of classes that provide a pooling
data source. Its very similiar to the one I sent in a few months ago.
Differences are
1) Abit more comments
2) Using pgsqlDriver.properties rather than psqlProps.properties
for the property reader
3) Its wrapping all the returned classes so exceptions can be caught.
As far as point three above goes, if my classes are accepted, I'd rather
patch the jdbc2 classes to notify the driver instead of wrapping.
The code is usable now, but your millage may varry. Please take a look
and comment.
Thanks.
=====
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
Вложения
Hi Ned, How does your implementation relate to the Exoffice XA package? I think that the XA layer is very well implemented. My instinctive approach would be to add things to the Exoffice package, if we you/we need something extra at the PooledConnection level. We may also want to separate the two layers into distinct packages, but then we need to (hopefully only slightly) change the XA package (which, in its current form, works very nicely for me). Peter > -----Original Message----- > From: Ned Wolpert [mailto:wolpert@yahoo.com] > Sent: Saturday, December 22, 2001 7:38 PM > To: pgsql-jdbc@postgresql.org > Subject: [JDBC] Submittal for JDBC Pooling driver (For 7.3) > > > Folks- > > I wasn't going to submit this code until 7.2 was released, but I've > wanted to have it available for folks to examine. I'm hoping > to get it > in the 7.3 release. Its a set of classes that provide a pooling > data source. Its very similiar to the one I sent in a few months ago. > Differences are > 1) Abit more comments > 2) Using pgsqlDriver.properties rather than psqlProps.properties > for the property reader > 3) Its wrapping all the returned classes so exceptions can > be caught. > As far as point three above goes, if my classes are accepted, > I'd rather > patch the jdbc2 classes to notify the driver instead of wrapping. > The code is usable now, but your millage may varry. Please > take a look > and comment. > > Thanks. > > ===== > 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 >
Peter- No, this implementation is not related to the Exolab project Tyrex, which I believe is the one you're refering to. This implementation is so that the JDBC driver has an internal pooling system to make the driver compatiable with the jdbc2.0 optional spec. With this implementation, you can still use the Tyrex package for their pooling system. This just extends the current JDBC driver implementation. I submitted this package to help bring the JDBC driver up to 2.0 compliance. --- Kov�cs_P�ter <peter.kovacs@sysdata.siemens.hu> wrote: > Hi Ned, > > How does your implementation relate to the Exoffice XA package? I think > that > the XA layer is very well implemented. My instinctive approach would be > to > add things to the Exoffice package, if we you/we need something extra at > the > PooledConnection level. We may also want to separate the two layers into > distinct packages, but then we need to (hopefully only slightly) change > the > XA package (which, in its current form, works very nicely for me). > > Peter > > > -----Original Message----- > > From: Ned Wolpert [mailto:wolpert@yahoo.com] > > Sent: Saturday, December 22, 2001 7:38 PM > > To: pgsql-jdbc@postgresql.org > > Subject: [JDBC] Submittal for JDBC Pooling driver (For 7.3) > > > > > > Folks- > > > > I wasn't going to submit this code until 7.2 was released, but I've > > wanted to have it available for folks to examine. I'm hoping > > to get it > > in the 7.3 release. Its a set of classes that provide a pooling > > data source. Its very similiar to the one I sent in a few months ago. > > Differences are > > 1) Abit more comments > > 2) Using pgsqlDriver.properties rather than psqlProps.properties > > for the property reader > > 3) Its wrapping all the returned classes so exceptions can > > be caught. > > As far as point three above goes, if my classes are accepted, > > I'd rather > > patch the jdbc2 classes to notify the driver instead of wrapping. > > The code is usable now, but your millage may varry. Please > > take a look > > and comment. > > > > Thanks. > > > > ===== > > 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 > > ===== 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
Ned,
I am referring to code under the PostgreSQL CVS repository in the directory
src\interfaces\jdbc\org\postgresql\xa plus the class in
src\interfaces\jdbc\org\postgresql\PostgresqlDataSource.java. There is no
indication that this code would be part of a project called Tyrex (or any
project other than PostgreSQL for that matter).
My understanding is that with this code ("xa" package & the class
PostgresqlDataSource) the driver fully meets the requirements set out in
sections "Connection Pooling" and "Distributed Transactions" of the JDBC 2.0
Optional Package Spec. (Distributed transactions are supported by the
Exoffice package only to the extent the underlying backend supports them.
That is, in case of PostgreSQL only one_phase_commit is meaningful. But due
to lack of support in the backend, you would not want to use PostgreSQL in
distributed transactions anyway.)
Also, my understanding of the optional spec is that implementing a "pooling
system" is the responsibility of the application server provider. The "xa"
package already provides the interface which the application server provider
will have to rely on to implement connection pooling. I admit that there is
(probably) a small twist in the behaviour of the Exoffice implementation:
because a physical PostgreSQL connection cannot join a transaction initiated
by another physical PostgreSQL connection, a physical connection
participating in a transaction is "pooled" between XAConnections
representing the same transaction. This means that physical connections may
be decoupled for a limited period of time (in the worst case by the time the
transaction timeout expires) from their logical representation
(XAConnections) dealt with by the application server vendor's pooling
system. This means that, now and then for a limited period of time, there
may exists more open physical connections than the application server
vendor's pooling system might think. (There is also another
resource/physical connection leakage potential which I discuss in another
related thread. But this one is rather a buglet.)
Again, this behaviour is due to the limitation in the PosgtreSQL backend
(physical connections cannot share the same transaction (is it accurate?))
and I think this irregularity is a small price to pay for the ability to
integrate PostgreSQL in a very demanding environment (even if the scope of
this integration is limited to what PostgreSQL is really capable
(one_phase_commit)).
(Just a brief recap: the XADataSource extends the ConnectionPoolDataSource
interface and the XAConnection interface implements the PooledConnection
interface.)
Peter
> -----Original Message-----
> From: Ned Wolpert [mailto:wolpert@yahoo.com]
> Sent: Wednesday, January 02, 2002 3:32 PM
> To: Kovács Péter; pgsql-jdbc@postgresql.org
> Subject: RE: [JDBC] Submittal for JDBC Pooling driver (For 7.3)
>
>
> Peter-
>
> No, this implementation is not related to the Exolab project Tyrex,
> which I believe is the one you're refering to. This implementation
> is so that the JDBC driver has an internal pooling system to make the
> driver compatiable with the jdbc2.0 optional spec.
>
> With this implementation, you can still use the Tyrex
> package for their
> pooling system. This just extends the current JDBC driver
> implementation. I submitted this package to help bring the JDBC driver
> up to 2.0 compliance.
>
> --- Kovács_Péter <peter.kovacs@sysdata.siemens.hu> wrote:
> > Hi Ned,
> >
> > How does your implementation relate to the Exoffice XA
> package? I think
> > that
> > the XA layer is very well implemented. My instinctive
> approach would be
> > to
> > add things to the Exoffice package, if we you/we need
> something extra at
> > the
> > PooledConnection level. We may also want to separate the
> two layers into
> > distinct packages, but then we need to (hopefully only
> slightly) change
> > the
> > XA package (which, in its current form, works very nicely for me).
> >
> > Peter
> >
> > > -----Original Message-----
> > > From: Ned Wolpert [mailto:wolpert@yahoo.com]
> > > Sent: Saturday, December 22, 2001 7:38 PM
> > > To: pgsql-jdbc@postgresql.org
> > > Subject: [JDBC] Submittal for JDBC Pooling driver (For 7.3)
> > >
> > >
> > > Folks-
> > >
> > > I wasn't going to submit this code until 7.2 was
> released, but I've
> > > wanted to have it available for folks to examine. I'm hoping
> > > to get it
> > > in the 7.3 release. Its a set of classes that provide a pooling
> > > data source. Its very similiar to the one I sent in a
> few months ago.
> > > Differences are
> > > 1) Abit more comments
> > > 2) Using pgsqlDriver.properties rather than psqlProps.properties
> > > for the property reader
> > > 3) Its wrapping all the returned classes so exceptions can
> > > be caught.
> > > As far as point three above goes, if my classes are accepted,
> > > I'd rather
> > > patch the jdbc2 classes to notify the driver instead of
> wrapping.
> > > The code is usable now, but your millage may varry. Please
> > > take a look
> > > and comment.
> > >
> > > Thanks.
> > >
> > > =====
> > > 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
> > >
>
>
> =====
> 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
>
--- Kov�cs_P�ter <peter.kovacs@sysdata.siemens.hu> wrote:
> My understanding is that with this code ("xa" package & the class
> PostgresqlDataSource) the driver fully meets the requirements set out in
> sections "Connection Pooling" and "Distributed Transactions" of the JDBC
> 2.0 Optional Package Spec. (Distributed transactions are supported by
the
Yes..
> Exoffice package only to the extent the underlying backend supports
> them. That is, in case of PostgreSQL only one_phase_commit is
meaningful.
> But due to lack of support in the backend, you would not want to use
> PostgreSQL in distributed transactions anyway.)
Not yet. :-)
> Also, my understanding of the optional spec is that implementing a
> "pooling system" is the responsibility of the application server
> provider. The "xa" package already provides the interface which the
Well, sorta. The JDBC vendor (us in this case) can supply the
pooled JDBC connection. Specifically, by implementing the
ConnectionPoolDataSource and PooleConnection from the jdbc2 optional
spec. It doesn't have to be the application server provide. (Example,
oracle provides one.)
[ .. ]
> Again, this behaviour is due to the limitation in the PosgtreSQL backend
> (physical connections cannot share the same transaction (is it
> accurate?))
> and I think this irregularity is a small price to pay for the ability to
> integrate PostgreSQL in a very demanding environment (even if the scope
> of this integration is limited to what PostgreSQL is really capable
> (one_phase_commit)).
I can agree with that. Let me ask you this; what is your application
server setup? (Weblogic? JBoss? WebSphere?) Is the current CVS XA
classes usable in a production environemnt, or does the 'irregularities'
cause problems with the application server? (I assume you have stress-
tested your environment.)
> (Just a brief recap: the XADataSource extends the
> ConnectionPoolDataSource interface and the XAConnection interface
> implements the PooledConnection interface.)
Yes, but the ConnectionPoolDataSource can exist outside of the XA side.
So, what I'm trying to do is get the ConnectionPooling side working,
outside of the XA side. My submittal is just a 'first draft' if you will,
which is why its for 7.3, not 7.2. There are some changes that will
be needed, and a seperation of classes. (You'd note that some classes
implement 'too much', and should be refactored.) I wanted to get the core
functionality done first, then setup the classes in a more 'clean'
way. Once thats done, then I'd look at modifing the XA implementation
we have to extend the new pooling setup. I want the XA implementation
ready to make full use of the database when it gets to be two-phase
commit capable.
Currently, I had thought that the XA implementation wouldn't work
properly, partially because the database doesn't support two-phase
commits, and the application server cannot easilly 'fake it'. However,
in your environment, it sounds like you're using them with Tyrex
with success. Do you have multiple database in use in your production
environment?
=====
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
> Well, sorta. The JDBC vendor (us in this case) can supply the > pooled JDBC connection. Specifically, by implementing the > ConnectionPoolDataSource and PooleConnection from the jdbc2 optional > spec. It doesn't have to be the application server provide. (Example, > oracle provides one.) I am not sure I understand 100% what you mean here, therefore (to avoid reiterating what might be the obvious) let me ask this: Having said what we've said: do you agree that you/we do not need to implement "an internal pooling system to make the driver compatiable with the jdbc2.0 optional spec"? My understanding of the spec is that the ConnectionPoolDataSource and PooledConnection should be implemented in such a way as to allow a compliant pooling system (by whomever it is provided: the database vendor or an application server vendor) to implement its own pooling mechanism using the ConnectionPoolDataSource and PooledConnection instances provided by the JDBC-driver vendor. And even though the spec does not say a word about whether an implementation (by the JDBC-driver vendor) of the ConnectionPoolDataSource or PooledConnection interfaces should, should not, may optionally or cannot include an _internal_ pooling mechanism, in my interpretation of the spec, the only reason for the ConnectionPoolDataSource or PooledConnection interfaces to exist is to provide an interface for an "external" pooling, so pooling simply does not belong into the implementation of these interfaces. > I can agree with that. Let me ask you this; what is your application > server setup? (Weblogic? JBoss? WebSphere?) Is the current CVS XA > classes usable in a production environemnt, or does the > 'irregularities' > cause problems with the application server? (I assume you > have stress- > tested your environment.) I have to admit that I am in the prototyping phase. I did not perform any stress-tests with the Exoffice driver or with the PostgreSQL backend (neither in combination nor separately). I use none of the available application servers. I am building a custom application system framework with a standard naming service (jndi), a transaction service (implementing jta) and security services. The later one consists of a custom descriptor based access control mechanism and a standard message protection mechanism (SSL). But let me reverse the question: What is your experience with PostgreSQL and the Exoffice xa pack? What kind of problem have you experienced with this combination (if any)? > Yes, but the ConnectionPoolDataSource can exist outside of > the XA side. > So, what I'm trying to do is get the ConnectionPooling side working, > outside of the XA side. My submittal is just a 'first draft' > if you will, > which is why its for 7.3, not 7.2. There are some changes that will > be needed, and a seperation of classes. (You'd note that some classes > implement 'too much', and should be refactored.) I wanted to > get the core > functionality done first, then setup the classes in a more 'clean' > way. Once thats done, then I'd look at modifing the XA implementation > we have to extend the new pooling setup. I want the XA implementation > ready to make full use of the database when it gets to be two-phase > commit capable. > > Currently, I had thought that the XA implementation wouldn't work > properly, partially because the database doesn't support two-phase > commits, and the application server cannot easilly 'fake it'. > However, > in your environment, it sounds like you're using them with Tyrex > with success. Do you have multiple database in use in your production > environment? What I have in mind with my application framework is an environment where I can use PostgreSQL for isolated transactions with the same (standard) APIs as 2pc-capable DMBSs for distributed transactions. In other words, PostgreSQL would be completely interchangeable with, say, Oracle, as long as the DBMS is supposed to carry out only isolated transactions. I do not know how much work does it take to build support for distributed transactions into the PostgreSQL backend, but I do not expect it to happen any time soon. And in the meantime, I think that PostgreSQL is too good (even if I do not consider that it is free) not to be used (for the work it can do). Peter
--- Kov�cs_P�ter <peter.kovacs@sysdata.siemens.hu> wrote: > I am not sure I understand 100% what you mean here, therefore (to avoid > reiterating what might be the obvious) let me ask this: > Having said what we've said: do you agree that you/we do not need to > implement "an internal pooling system to make the > driver compatiable with the jdbc2.0 optional spec"? Well, no. I do not agree. (See below for why) > And even though the spec does not say a word about > whether an implementation (by the JDBC-driver vendor) of the > ConnectionPoolDataSource or PooledConnection interfaces should, should > not, may optionally or cannot include an _internal_ pooling mechanism, in > my interpretation of the spec, the only reason for the > ConnectionPoolDataSource > or PooledConnection interfaces to exist is to provide an interface for > an > "external" pooling, so pooling simply does not belong into the > implementation of these interfaces. The spec outlines how to talk to a ConnectionPoolDataSource, and talk to a PooledConnection, etc. So yes, you are correct. We only _need_ to implement the API to allow for the JDBC driver classes only. However, what I would like to provde is the (as you say) 'optional' pool implementation. Why? One reason is so that we can write test cases that work on the jdbc driver in a pool, and test our functionality without having to install secondary packages. Also, having a pool system that works out-of-the-box is good for our user base who pick up the system from day one. I know abunch of folks who use this driver with PoolMan simply because we do not provide a pooling driver. I do not want to replace either PoolMan or Tyrex, but rather give another option that works out-of-the-box. (Just like oracle) > I have to admit that I am in the prototyping phase. I did not perform > any > stress-tests with the Exoffice driver or with the PostgreSQL backend > (neither in combination nor separately). I use none of the available > application servers. I am building a custom application system framework > with a standard naming service (jndi), a transaction service > (implementing jta) and security services. The later one consists of a > custom descriptor based access control mechanism and a standard message > protection mechanism (SSL). Check out the tomcat4 mailing lists about tyrex. Some people have problems with it. I've not been following it too closely, but I do remember some issues people had. Specifically, they were associated with pooling and tyrex. > But let me reverse the question: > What is your experience with PostgreSQL and the Exoffice xa pack? What > kind of problem have you experienced with this combination (if any)? Well, I have not used tyrex since I having a TP monitor doesn't help my current applications with postgres. (no 2-phase commits) I've gotten a few apps in production with postgres, and a few in development. Generally, my experience has been with Servlet engines going to postgresql (using poolman) or JBoss going to postgresql. (Using poolman for servlet development, and minivera(sp) which is in JBoss) Back in my weblogic days, we had weblogic going to oracle and prototyped weblogic going to postgres, but never did that in production. (Once someone pays that much for weblogic, oracle seems cheap. ;-) I'm now working on a Apache axis application that uses castor jdo to go to postgres, which does not use tyrex at this point in time. > What I have in mind with my application framework is an environment > where I can use PostgreSQL for isolated transactions with the same > (standard) APIs as 2pc-capable DMBSs for distributed transactions. In > other words, PostgreSQL would be completely interchangeable with, say, > Oracle, as long as > the DBMS is supposed to carry out only isolated transactions. I do not > know > how much work does it take to build support for distributed transactions > into the PostgreSQL backend, but I do not expect it to happen any time > soon. Maybe someone else on the list can answer this one. I had believed that it was going to be worked on in 7.3, but that's likely not decided at this point. > And in the meantime, I think that PostgreSQL is too good (even if I do > not consider that it is free) not to be used (for the work it can do). True. Might I suggest you examine the work in the JBoss group? Their 3.0 release is going to provide clustering support I believe. Since they have postgres as an option, they may have already looked into this issue. Sounds like you're doing what they did. ===== 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
> -----Original Message----- > From: Ned Wolpert [mailto:wolpert@yahoo.com] > Sent: Wednesday, January 02, 2002 8:26 PM > To: Kovács Péter; pgsql-jdbc@postgresql.org > Subject: RE: [JDBC] Submittal for JDBC Pooling driver (For 7.3) ... > The spec outlines how to talk to a ConnectionPoolDataSource, and talk > to a PooledConnection, etc. So yes, you are correct. We only > _need_ to > implement the API to allow for the JDBC driver classes only. > > However, what I would like to provde is the (as you say) 'optional' > pool implementation. Why? One reason is so that we can write test > cases that work on the jdbc driver in a pool, and test our > functionality > without having to install secondary packages. Also, having a pool > system that works out-of-the-box is good for our user base who pick up > the system from day one. I know abunch of folks who use this driver > with PoolMan simply because we do not provide a pooling driver. I do > not want to replace either PoolMan or Tyrex, but rather give another > option that works out-of-the-box. (Just like oracle) 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. Please, look at the pictures in the spec, they're very expressive (page 20 and page 22 [and the same positioning of the pooling logic for the XA interfaces on 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 (if you absolutely want to do it as part of the PostgreSQL project) called something like "org.postgresql.middleware" and it would use the ConnectionPoolDataSource or PooledConnection interface implementations "org.postgresql.jdbc2". Oracle may have implemented an "internal pooling system" in its JDBC2 extensions (and the tomcat guys may be happy with the Oracle driver for this reason), but do not forget, Oracle also has a complete J2EE offering, so it is not a "pure" JDBC2 vendor. (I suspect that they do not have any pooling in the middleware layer...and the result: their DBMS will perform the best with their app server [with other appserver you'll have the overhead of duplicating the pooling with no real functional benefit] and their app server will perform the best with their DMBS [with other DBMS you may have no pooling at all, if this other DBMS sticks to the spec and expects the middleware to provide the pooling], and they may even benefit --performancewise-- from implementing the pooling directly in the jdbc driver, who knows? Synergy a la Microsoft: declare to be compliant, but do not stick to the spec excessively.) > > Check out the tomcat4 mailing lists about tyrex. Some people > have problems > with it. I've not been following it too closely, but I do > remember some > issues people had. Specifically, they were associated with > pooling and > tyrex. > 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. The Exoffice xa package very elegantly implements a very complicated functionality (with the added complexity that the package integrates RDBMSs with limited transactional capability). > True. Might I suggest you examine the work in the JBoss group? Their > 3.0 release is going to provide clustering support I believe. > Since they > have postgres as an option, they may have already looked into > this issue. > Sounds like you're doing what they did. 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 docs to this effect, but they surely did not support message protection (over applets). Now I cannot even check, because you have to buy the docs. (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. OK. I rest my case. (And let you rest yours :-)). Let's take some rest. Peter > > ===== > 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 >
--- 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
Folks- I'm re-examing the PostgresDataSource class, and it seems that I missed a few things. I need someone to verify what it is I'm looking at. This is based on my pooled stuff I submitted eariler, and the current conversation that has been going on about my submittal. Basically, it seems that the XADataSourceImpl is a working pooling manager. It is an abstract class, only extended by PostgresqlDataSource. The XADataSourceImpl provides the access to the pool from their method newConnection() and releaseConnection(), neither of which are called elsewhere. It looks like the code was expecting the org.postgresql.jdbc2.Connection object to 'release' it if it was called by the datasource, when the connection was closed, but the Connection class was never modified. In short, the pool is almost there already, just not complete. The class PostgresqlDataSource _can_ pool, it just doesn't. Does this look like a proper analysis to others? I can do one of two things at this point, and I would like people's opinion as to what I should do. One, I can continue working on my pool manager, which will extend XADataSourceImpl and will still have to wrap the connection classes to notify my pooling manager of changes that occurs. or Two, create a set of patches that will impact the jdbc2 package and PostgresDataSource class to finish what was started. What do you think folks? I'm starting to lean to option two, but would like to hear other people's opinions. If we pick two, that means that my pooling manager is _part_ of the PostgresDataSource, not a seperate class. Could some of the CVS committers comment on this? (Also, I'll be having patches for basically all the classes in the jdbc2 and xa package.) ===== 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