proxool-developer — Developer's discussion list

Re: [Proxool-developer] Proxool settings

[Bill H. <bi...@lo...>]

Hi Jean,

On Mon, 2003-05-05 at 00:31, Jean-Henry Berevoescu wrote:

> I found the problem: it was happening with some connections I was not
> properly releasing. Sorry for the missunderstanding.

No problem. I was just composing my reply to your original mail. I have
some comments to make anyway :)

> I'd like to close only the connections having problems

You kind of can do this using:

ProxoolFacade.killConnection(alias, id, merciful);

But you need to know the connection ID for that to work and that's not
immediately available to you. I guess we probably need a method like:

ProxoolFacade.killConnection(connection, merciful);

(As a reminder, the merciful parameter allows you to decide whether to
kill the connection immediately (merciless) or when it is next inactive
(merciful).

I think I will add that method for the next release.

> > Proxool ... keeps closing my connections that are older than the 
> > "maximum-active-time". 

More accurately, connections that are active without having been closed
properly and are old than this time.

> > So I set "house-keeping-sleep-time" to, say, 5 seconds and I also
> > have "house-keeping-test-sql" set to a valid light-weight SQL query.
> > But all these do not help - proxool keeps killing all the connections
> > no matter what and it keeps the "invalid" ones.

Yes, the house keeper only tests inactive connections. During busy
times, this means that some connections might not get tested for several
sweeps of the house keeper.

Let me know if you have any other queries.

Cheers,
Bill

Re: [Proxool-developer] Proxool settings

[Jean-Henry B. <ber...@ne...>]

Hi,
I found the problem: it was happening with some connections I was not
properly releasing. Sorry for the missunderstanding.

Jean



Jean-Henry Berevoescu wrote:

>
> Hi,
> I have a little problem and it might be due to some seeting I overlook.
> I want to maintain the valid connections alive and only kill the faulty
> ones. In my setup it happens to get SQL statements that block for 
> seemingly
> unlimited time and I'd like to close only the connections having 
> preoblems
> like these.
> Proxool works for me all right in all the respects, but it keeps 
> closing my
> connections that are older than the (default or programatically set)
> "maximum-active-time". From the documentation I learned that
> I can use the "house-keeping" facility in order to kill invalid 
> connections.
> So I set "house-keeping-sleep-time" to, say, 5 seconds and I also
> have "house-keeping-test-sql" set to a valid light-weight SQL query.
> But all these do not help - proxool keeps killing all the connections
> no matter what and it keeps the "invalid" ones.
>
> I will be very happy if I could use a call to a version of 
> "reallyClose()"
> method (and forget about all the settings I talked about) - since I
> have a way to detect the "faulty statements" in my program, but
> "reallyClose()" is unusable from outside the Proxool packages.
>
> Any tips on these problems will be highly appreciated.
>
> Thanks,
> Jean
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Proxool-developer mailing list
> Pro...@li...
> https://lists.sourceforge.net/lists/listinfo/proxool-developer
>

-- 
Your favorite stores, helpful shopping tools and great gift ideas. 
Experience the convenience of buying online with Shop@Netscape! 
http://shopnow.netscape.com/

[Proxool-developer] Proxool settings

[Jean-Henry B. <ber...@ne...>]

Hi,
I have a little problem and it might be due to some seeting I overlook.
I want to maintain the valid connections alive and only kill the faulty
ones. In my setup it happens to get SQL statements that block for seemingly
unlimited time and I'd like to close only the connections having preoblems
like these.
Proxool works for me all right in all the respects, but it keeps closing my
connections that are older than the (default or programatically set)
"maximum-active-time". From the documentation I learned that
I can use the "house-keeping" facility in order to kill invalid connections.
So I set "house-keeping-sleep-time" to, say, 5 seconds and I also
have "house-keeping-test-sql" set to a valid light-weight SQL query.
But all these do not help - proxool keeps killing all the connections
no matter what and it keeps the "invalid" ones.

I will be very happy if I could use a call to a version of "reallyClose()"
method (and forget about all the settings I talked about) - since I
have a way to detect the "faulty statements" in my program, but
"reallyClose()" is unusable from outside the Proxool packages.

Any tips on these problems will be highly appreciated.

Thanks,
Jean

[Proxool-developer] 0.7.2 coming soon :(

[Bill H. <bi...@lo...>]

Hi all,

A couple of glitches in the 0.7.1 release:

1. I had moved the draft BasicDataSource class into the src/java-sandbox
tree (for code that compiles but doesn't really work). But I'd left the
test class in the src/java-test. This means that the test classes don't
compile from Ant.

2. For some reason, I'd managed to fix a ConfigurationListener bug and
then make a small (but important) change without rerunning the tests.
They failed. It's only important if you register a ConfigurationListener
and the only consequence is that you get events too frequenttly. How I
managed to release without testing is stupid. Mea culpa.

I will make a 0.7.2 release in the next few days to fix these problems.

Cheers,
Bill

[Proxool-developer] Release 0.7.1

[Bill H. <bi...@lo...>]

Hi all,

Just released 0.7.1 at long last.

Let me know how you get on with it. 

Cheers,
Bill

Re: [Proxool-developer] Threads when using a lot of pools

[Martin C. <mus...@us...>]

Just an old post that I might as well respond too..

 > At the moment it is hard coded to just one thread for house keeping and
 > prototyping, but it would be easy to increase that. I wonder how we
 > should decide how many threads to have?


The question is how much "housekeeping" do these threads do? Two threads 
seem reasonable. I imagine that housekeeping isn't a real high priority 
(esspecially around my house it seems;), so why bloat the memory 
footprint just to clean up a few connections sooner.

 > Or we could do some measurements. Work out how much idle time the
 > threads have and only start a new thread if the existing threads aren't
 > coping.


Perhaps keeping a small pool of management threads would make sense, and 
then have one that manages their dispatch. Again though probably not a 
big deal. Threads are memory hogs, and if you can limit them more the 
better.

Martin

Re: [Proxool-developer] 0.7.1 Plan

[Martin C. <mus...@us...>]

> Great to see some activity on the list again.

Yeah, I too had disappeared into obscurity!

> I've started on the website stylesheets. Hope to check in some stuff for 0.8
> during the next week. proxool-doc does currently not build on my computer. I
> get a NPE from the i10n module of the DocBook stylesheets. Probably
> something to do with my computers locale being Norwegian. I'll try to figure
> it out...

Before you pull your hair out on this one I have attached a few links. 
Basically you need to upgrade your version of Xalan, but because Sun 
release Xalan as part of their JRE 1.4.x (and a beta/buggy version at 
that) you have to jump through some hoops to make it work. And 
unfortunatley with each incremental release of 1.4.x they have not 
updated the Xalan version. Ssome of the bugs for the Xalan version 
released with the JRE 1.4.x are just downright nasty and I would bet 
localisation issues could be included.

http://lists.oasis-open.org/archives/docbook-apps/200212/msg00078.html

http://java.sun.com/j2se/1.4.1/docs/guide/standards/

Perhaps we look at Saxon instead, which we can distribute with the 
source code and probably little headache.

BTW I still owe the development document to convert....

Martin

RE: [Proxool-developer] 0.7.1 Plan

[<chr...@em...>]

Yeah!

Great to see some activity on the list again.

I've also been busy with other stuff for a while.

I've started on the website stylesheets. Hope to check in some stuff for 0.8
during the next week. proxool-doc does currently not build on my computer. I
get a NPE from the i10n module of the DocBook stylesheets. Probably
something to do with my computers locale being Norwegian. I'll try to figure
it out...

I'm also planning to finish the tests for the JMXConfigurator (currently in
the sandbox) so that we have JMX support in 0.8.


CHR

> -----Original Message-----
> From: pro...@li...
> [mailto:pro...@li...]On Behalf Of Bill
> Horsman
> Sent: 11 April 2003 00:13
> To: Proxool Developer List
> Subject: [Proxool-developer] 0.7.1 Plan
>
>
> Hi all,
>
> Sorry it's been so quiet. I've been a bit busy. But Proxool has never
> strayed far from my mind.
>
> I have discovered a small bug in 0.7.1-RC1 to do with the
> ConfigurationListenerIF getting its definitionUpdated event getting
> called everytime you pass a Properties object to the Driver (whether it
> represents a change or not). Thanks to Gard Skauge for spotting that
> one. So I'm going to fix that in the next few days.
>
> And, for a little light relief, I'm starting to add support for the
> DataSource interface. Either I have massively underestimated the task or
> it should be fairly easy. I think I'm about to find out. DataSource will
> probably find its way into the "sandbox" for the 0.7.1 release.
>
> I hope you are all thriving out there and haven't forgotten about
> Proxool, despite the fact it's all been a bit quiet recently.
>
> Cheers,
> --
>   Bill Horsman
>   Proxool
>   http://proxool.sourceforge.net
>   ICQ: 119577180
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView,
> The debugger
> for complex code. Debugging C/C++ programs can leave you feeling lost and
> disoriented. TotalView can help you find your way. Available on
> major UNIX
> and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> Proxool-developer mailing list
> Pro...@li...
> https://lists.sourceforge.net/lists/listinfo/proxool-developer

[Proxool-developer] 0.7.1 Plan

[Bill H. <bi...@lo...>]

Hi all,

Sorry it's been so quiet. I've been a bit busy. But Proxool has never
strayed far from my mind.

I have discovered a small bug in 0.7.1-RC1 to do with the
ConfigurationListenerIF getting its definitionUpdated event getting
called everytime you pass a Properties object to the Driver (whether it
represents a change or not). Thanks to Gard Skauge for spotting that
one. So I'm going to fix that in the next few days.

And, for a little light relief, I'm starting to add support for the
DataSource interface. Either I have massively underestimated the task or
it should be fairly easy. I think I'm about to find out. DataSource will
probably find its way into the "sandbox" for the 0.7.1 release.

I hope you are all thriving out there and haven't forgotten about
Proxool, despite the fact it's all been a bit quiet recently.

Cheers,
-- 
  Bill Horsman
  Proxool
  http://proxool.sourceforge.net
  ICQ: 119577180

[Proxool-developer] 0.7.1-RC1 is released

[Bill H. <bi...@lo...>]

Hi all,

0.7.1-RC1 is now released. It's hidden. Which means it's not mentioned
on the home page or the project page. But you can download it from here:

http://proxool.sourceforge.net/dev/download.html

I *think* I like the idea of these hidden releases. The idea is that
some of you lot take a look and check that it works in your
environments. And that all the doc looks ok. And that I have included
all the source code in the source release, etc.

It is all, in fact, automated with an Ant script. But I keep changing it
and improving the script :) Hence the need to double check for stupid
things. It is now almost all done from the compile farm. As soon as we
get things done by DocBook it will start to become even easier. One day,
releases will be easier than they are now. This one took several hours.
Grr.

I'd really appreciate some feedback quite soon. If it looks good I want
to release before Saturday (I go on holiday, er I mean vacation, for a
week on Saturday). I wouldn't normally want to release just before a
holiday but 0.7 has bugs in it (the unit tests fail quite often) and I
don't like that.

Cheers,
-- 
  Bill Horsman
  Proxool
  http://proxool.sourceforge.net
  ICQ: 119577180

[Proxool-developer] 0.7.1

[Bill H. <bi...@lo...>]

Hi all,

I'm going to be releasing a bug fix version 0.7.1 in the next few days.
I expanded the tests a lot recently and it brought a few concurrency
issues to light. 

I've been learning a lot about concurrency in the past few days,
especially with respect to testing. It seems testing for concurrency
stuff is even harder than writing the damn code. The tests now allow for
all sorts of things happening in strange orders that are hard to
predict.

I've also imported a new concurrent package that I got from here:

http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html

I don't want to go into a lot of depth about this right now because I'm
tired, but I do believe this makes Proxool a lot more robust that it was
before. The sort of problems it fixes would only be experienced under
very heavy loads.

Although this is just a bug fix release there has been a _lot_ of
refactoring going on behind the scenes. If anyone wants to play with the
CVS version as it is now then feel free. There are no outstanding bugs
that I am aware of.

Don't forget you can pick up the latest JUnit reports at:

http://proxool.sourceforge.net/test.html

I'll release 0.7.1RC1 as a hidden release sometime soon and hope to get
0.7.1 final out before the end of the week.

Note - I'm off snowboarding for a week from 15 - 22 March :) 

Cheers,
-- 
  Bill Horsman
  Proxool
  http://proxool.sourceforge.net
  ICQ: 119577180

[Proxool-developer] New Proxool-user list

[Bill H. <bi...@lo...>]

Hi all,

I've just created a new list for Proxool users. Perhaps the members of
this developer list would also like to subscribe there? 

  http://lists.sourceforge.net/lists/listinfo/proxool-user

Cheers,
-- 
  Bill Horsman
  Proxool
  http://proxool.sourceforge.net
  ICQ: 119577180

Re: [Proxool-developer] proxool architecture

[Bill H. <bi...@lo...>]

Hi Alex,

On Thu, 2003-03-06 at 08:38, Alex wrote:

> i didn't find any other mailing list to post my questin to, so, i post it
> here, it may be off topic...

Not at all. But you're right, there should be a proxool-user list. I'll
create one.

> i've configured web.xml for my context to load ServletConfigurator at
> context startup.

That's a good start. 

> 1.
> when i request a connection, using:
>  Class.forName("org.logicalcobwebs.proxool.ProxoolDriver");
>  try {
>   connection = DriverManager.getConnection("proxool.example" +
>    ":com.mysql.jdbc.Driver" +
> 
> ":jdbc:mysql://192.168.17.17:3306/testdb?user=tomcat&password=tomcat&autoRec
> onnect=true");
>  .............
> , a pool is being created and it return a connection.
> 
> So, the connection pool is being created at the first
> DriverManager.getConnection(....) request ?
> If the pool named 'example' doesn't exists, it creates a new one ?

Yes. This is how it works. Each pool is uniquely identified by its
alias. If the alias hasn't been used before it will create this pool for
you.

> 2.
> When i run again that code, it doesn't create a new pool, it uses the
> 'example' pool and returns a connection from that pool.

Oh good. That's what it's supposed to do :)

> How does proxool knows that 'example' pool exists ? 

Because it keeps a track of what pools are registered and reuses them.

> 3. Is there any way to reference the pool object ?
> because i don't wanna use:
>  Class.forName("org.logicalcobwebs.proxool.ProxoolDriver");
>  try {
>   connection = DriverManager.getConnection("proxool.example" +
>    ":com.mysql.jdbc.Driver" +
> 
> ":jdbc:mysql://192.168.17.17:3306/testdb?user=tomcat&password=tomcat&autoRec
> onnect=true");
> every time i request a new connection.

Yep, sure there is. The documentation doesn't seem to tell you though :)
I'll fix that today. Basically, all you have to do is use
"proxool.alias". So in your example:

  connection = DriverManager.getConnection("proxool.example");

will connect to the same database and reuse the same properties.

> Is there any way to use something like this:
>  a) create a new pool at context startup

Absolutley. I recommend it. Look at:

    http://proxool.sourceforge.net/servlets.html

for examples of how to setup the ServletConfigurator to register the
pool(s) based on an XML file.

Or, if for some reason you don't like that, you could do it
programmatically:

    http://proxool.sourceforge.net/configure.html

>  b) get connections from that pool like this:
> pool.getConnection(poolName[,...]);

No. You have to go through the ProxoolDriver. It's for your benefit
really; you want as few dependencies on Proxool in your code as
possible. Using the JDBC Driver makes it easier for you to switch to
another pool if you want (we hope you won't!).

>  c) shutdown that pool at context shutdown

That's a very wise thing to do. Again, see

    http://proxool.sourceforge.net/servlets.html

and look at Installation notes at the bottom, number 1. You need to call
ProxoolFacade.shutdown when you context shuts down (perhaps in a Servlet
destroy() method?). But, if you use ServletConfigurator and you don't
override the autoShutdown init parameter (defaults to true), then that
will happen automatically.

Feel free to post back here if you have any further questions - although
I will be creating a proxool-user list in the next 24 hours.

Cheers,
-- 
  Bill Horsman
  Proxool
  http://proxool.sourceforge.net
  ICQ: 119577180

[Proxool-developer] proxool architecture

[Alex <ale...@go...>]

i didn't find any other mailing list to post my questin to, so, i post it
here, it may be off topic...


i wanna use Proxool 0.7 into tomcat, but i can't understand how does it
work.

i've configured web.xml for my context to load ServletConfigurator at
context startup.

1.
when i request a connection, using:
 Class.forName("org.logicalcobwebs.proxool.ProxoolDriver");
 try {
  connection = DriverManager.getConnection("proxool.example" +
   ":com.mysql.jdbc.Driver" +

":jdbc:mysql://192.168.17.17:3306/testdb?user=tomcat&password=tomcat&autoRec
onnect=true");
 .............
, a pool is being created and it return a connection.

So, the connection pool is being created at the first
DriverManager.getConnection(....) request ?
If the pool named 'example' doesn't exists, it creates a new one ?

2.
When i run again that code, it doesn't create a new pool, it uses the
'example' pool and returns a connection from that pool.

How does proxool knows that 'example' pool exists ? (maybe this is a pretty
stupid question, but i don't get it)

3. Is there any way to reference the pool object ?
because i don't wanna use:
 Class.forName("org.logicalcobwebs.proxool.ProxoolDriver");
 try {
  connection = DriverManager.getConnection("proxool.example" +
   ":com.mysql.jdbc.Driver" +

":jdbc:mysql://192.168.17.17:3306/testdb?user=tomcat&password=tomcat&autoRec
onnect=true");
every time i request a new connection.

Is there any way to use something like this:
 a) create a new pool at context startup
 b) get connections from that pool like this:
pool.getConnection(poolName[,...]);
 c) shutdown that pool at context shutdown
?

Thanks in advance...
Alex

[Proxool-developer] Threads when using a lot of pools

[Bill H. <bi...@lo...>]

Hi,

I just fixed the unit tests so that each test (we have 47 now) cleans up
after itself. Some were getting left running and the house keeper and
prototyper threads were left running. This got me thinking about how
Proxool would scale up when using many pools.

The old way (at 0.7) had at least two threads per pool and some JDKs
(1.4.0_01 on Linux for instance) don't cope well with 30 odd threads. At
least, things start to get slow.

So I've just finished a painstaking rewrite of the house keeper and
prototyper code. There is now just one house keeper that looks at all
the pools. And one prototyper too.

A useful imapct of this rewrite was to simplify a lot of things. I
created a handful of new classes but at the same time reduced the
complexity of the ConnectionPool class (which is still over 750 lines
long).

At the moment it is hard coded to just one thread for house keeping and
prototyping, but it would be easy to increase that. I wonder how we
should decide how many threads to have? 

We could use a formula. Like, one house keeper for every five pools. And
have it so you could override that in the config.

Or we could do some measurements. Work out how much idle time the
threads have and only start a new thread if the existing threads aren't
coping. 

Cheers,
-- 
  Bill Horsman
  Proxool
  http://proxool.sourceforge.net
  ICQ: 119577180

[Proxool-developer] When connections fail

[Bill H. <bi...@lo...>]

Hi all,

This is a summary of an IM discussion between myself and Del Simmons
(who has subsequently joined this list - welcome Del).

Del has a setup where if a database fails than the IP is transparently
switched to a new database. When this happens, all the existing 
connections will be "bad".

If you have configured house-keeper-test-sql then they will be caught by
the next sweep of the house keeper, but that might not be for another 30
seconds or so and in the meantime you might refuse a lot of connections.
And if you are busy then you will have more active connections (and
active connections aren't tested, obviously).

If you configure fatal-sql-exception (you'll have to test on your
particular database what exception messages you are looking for) then
each connection will refuse exactly one client before destroying itself.

It would be nice to continue the client's execution with a new
connection - transparently. Only that is a bit tricky. Consider this:

  Connection connection = DriverManager.getConnection("proxool.example:org.hsqldb.jdbcDriver:jdbc:hsqldb:test");

  // Some preparation
  connection.setAutoCommit(false);
  Statement s = connection.prepareStatement("SELECT * FROM MY_TABLE;");  
  
  // Execute it (this is the bit that causes the SQLException because
  // the database is down.
  s.execute();

The problem is that Proxool won't know there's a problem until it tries
to execute the statement. If, at that point, it decides to try again
with a brand new connection then it will have to recreate the
preparation phase, and that might be a lot more complicated than this
example.

At the app level you might consider putting the whole of this code into
a short loop (if you're that interested in avoiding a refusal). But
making it transparent within Proxool is a little more involved.

A compromise might be that if we ever get a fatal sql exception then we
immediately wake up the house keeper thread so that we minimise the
refusals.

Another might be that we test each connection when we serve it to see if
it is ok. This might be some SQL (as defined in house-keeper-test-sql),.
but that will add an unacceptable performance overhead. Are there any
quick operations we can call on a Connection to check to see if it is
really connected to an operating database?

Regards,
-- 
  Bill Horsman
  Proxool
  http://proxool.sourceforge.net
  ICQ: 119577180

[Proxool-developer] Unit Testing and Reports

[Bill H. <bi...@lo...>]

Hi all,

I'm so proud of myself. We now get nightly (2300 PST) Junit reports
posted automatically:

http://proxool.sourceforge.net/reports/junit-cvs.html

You can also see the one for 0.7:

http://proxool.sourceforge.net/reports/junit-0.7.html

---

Incidentally, I can only get the unit tests to work consistently on JDK
1.4.1 (it doesn't work on 1.4.0). I'm am pretty sure this is only a
problem with the tests themselves and not Proxool.

It's all to do with threads. Sometimes, not all the time, something that
is supposed to happen takes a long time. Like the test to see that a
connection is automatically removed if it has been active for too long.
On 1.4.1 that happens within a second of one it's supposed to. With
1.4.0 it differs wildly.

I want to get to the bottom of this so I'll play around some more. But
in the meantime, you might experience some problems if you're using
1.4.0.

I don't have any data on what happens on Windows by the way. 

Cheers,
-- 
  Bill Horsman
  Proxool
  http://proxool.sourceforge.net
  ICQ: 119577180

[Proxool-developer] YaPoolman

[Bill H. <bi...@lo...>]

I was gazing around at the other pools out there and came across
YaPoolman. Registered 16 Jan 2003 it has just released 1.0 final.

It supports load balancing and fail over.

There's not much documentation yet but the project seems very active.
There's only one developer. I'm not sure if it is a fork of the Poolman
project or completely new. Like ours, it uses Proxy pattern to do the
pooling.

Cheers,
-- 
  Bill Horsman
  Proxool
  http://proxool.sourceforge.net
  ICQ: 119577180

Re: [Proxool-developer] Logging class refactoring?

[Bill H. <bi...@lo...>]

Martin,

On Fri, 2003-02-28 at 06:11, Martin Crawford wrote:

> I guess the question is why refactor over redistribute? To make a single 
> JAR the Ant script could unjar the commons-logging JAR and then jar it 
> back in the Proxool JAR.

Yes, that is tempting. The trouble is that because the package names
would remain the same it would conflict with the *real* commons-logging
if that too was on the classpath. 

Most of the time, that would be just fine, but if the user upgrades to a
new version yet proxool.jar is first on the classpath then the user
won't get the upgrade! Or worse still, get compile time errors because
of conflicts between the classes of the same name. 

The refactoring is pretty simple so we shouldn't have a problem with
keeping up with the latest versions.

This sounds wise to me. Anyone?

Cheers,
-- 
  Bill Horsman
  Proxool
  http://proxool.sourceforge.net
  ICQ: 119577180

[Proxool-developer] Logging class refactoring?

[Martin C. <mus...@us...>]

All.

So I've been porting documentation over and reading it as I go...

Question:

I understand that we wanted to remove the dependency of the 
commons-logging package. Mainly I guess because JDBC drivers standardly 
are one package. Additionally, because it would be good to keep the 
dependencies down.

I guess the question is why refactor over redistribute? To make a single 
JAR the Ant script could unjar the commons-logging JAR and then jar it 
back in the Proxool JAR.

True, we could potentially run into version issues in the future. Our 
trade off as I see it though is that we loose the reusability using 
existing implementations of Log (without refactoring them too). Plus we 
have a bit of a maintenance head ache on our hands.

I am sure there are some good arguements to refactor over redistribute? 
I'd be interested in hearing these arguments. Mainly because I've been 
considering this issue often in other projects and usually just rebunlde 
the JARs.

Cheers.
Martin

[Proxool-developer] Proxool IRC

[Christian N. <chr...@em...>]

We have set up an IRC channel for Proxool.

Server: oslo.no.eu.undernet.org
Port: 6660
Channel: Proxool

Everybody is weclome to join.

CHR

-- 
_______________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

Meet Singles
http://corp.mail.com/lavalife

Re: [Proxool-developer] Getting ready for 1.0

[Bill H. <bi...@lo...>]

On Wed, 2003-02-26 at 18:41, Martin Crawford wrote:

> Statement Cache

I'm not sure whether we should...

> DBCP offers it

Right! We will too then :)

> Roadmap that to 1.1...

I'll try and fix up a Roadmap page on the web site.

> Also on the Hibernate support I've spoken with the PM and he seems 
> accepting and it's tiny bit of code to write to implement. After the 
> documentation I can work on this. Trying to figure out who's code it 
> will be, Hibernate or Proxool.

I think it will all be within Hibernate. Good work! It will be great to
be included. Let me know if I can help with the adapter (or whatever it
is).

One thing I have just changed in anticipation of this is that it's now
possible to define the url and the driver as properties rather than
specifying them in the url. I have to do some testing on that though,
but I'll let you know...

Cheers,
-- 
  Bill Horsman
  Proxool
  http://proxool.sourceforge.net
  ICQ: 119577180

Re: [Proxool-developer] Getting ready for 1.0

[Martin C. <mus...@us...>]

> Yeah, we'll take a deep breath and support DataSource sometime. 1.1+ I
> think.

Sorry another competing feature that came to my attention from the 
Hibernate project is a Statement Cache. Not really sure "what" that 
implies, but DBCP offers it;) I guess it either will cache prepared 
statements or perhaps even non-prepared statements accorss connections. 
Roadmap that to 1.1...

Also on the Hibernate support I've spoken with the PM and he seems 
accepting and it's tiny bit of code to write to implement. After the 
documentation I can work on this. Trying to figure out who's code it 
will be, Hibernate or Proxool.

Cheers.
Martin

Re: [Proxool-developer] Getting ready for 1.0

[Bill H. <bi...@lo...>]

On Mon, 2003-02-24 at 18:09, Martin Crawford wrote:

> Now I've never used c3po or DBCP, but can someone point out what our 
> differences incase they ask.

c3p0 doesn't offer much on the web site. Still in alpha, no activity, no
doc. I don't want to dis the project, but it would imply that we don't
have to be at 1.0 to be included in Hibernate :)

dbcp on the other hand comes from the mighty Jakarta Commons and will
get a lot of respect because of that. But we seem to be a little maturer
and have a lot better doc.

-- 
  Bill Horsman
  Proxool
  http://proxool.sourceforge.net
  ICQ: 119577180

Re: [Proxool-developer] Getting ready for 1.0

[Martin C. <mus...@us...>]

 >
 > Yeah, we'll take a deep breath and support DataSource sometime. 1.1+ I
 > think.

Yeah.. no rush, but certainly a must at somepoint.... And don't ask me 
to do it;)

 >
 > I don't suppose they'll want to add Proxool support
 > until we are at 1.0. And that won't be for another month (I'm guessing).
 >

Timing would proabably be okay. Perhaps even for 1.1 if it was a soon 
release. There is no real indication of when Hibernate 2.0 is going to 
be release. But probably getting in before the next beta would be good.

 >
 >>>My opinion is that we shouldn't try and squeeze much more into 1.0 and
 >>>we should plant our feet firmly in the ground and say "it's ready!".
 >>>

Yup. I agree too.

 > Yeah, I asked for it! I think I'll add a RoadMap to the web site for all
 > this stuff. But I suppose I should wait for your doc freeze to be
 > complete first. Actually, I am just making a link fix now. Perhaps I
 > should just tell you what it is:
 >
 > listen.html has links to:
 > api/org/logicalcobwebs/proxool/StatisticsListenerIF.html, and
 > api/org/logicalcobwebs/proxool/StatisticsIF.html
 >
 > they should have the admin package in the path:
 > api/org/logicalcobwebs/proxool/admin/StatisticsListenerIF.html, and
 > api/org/logicalcobwebs/proxool/admin/StatisticsIF.html
 >

No prob. I haven't started yet:)

 >
 > Yeah, it would be great to be associated with Hibernate. Do you want to
 > talk to them, or shall I?

I've already popped my little nose around the project contributing a doc 
on Hibernate and XDoclet, and made an important feature request (yes, I 
only ask for the world on a platter;), I'd imagine it would be easy to 
get them on board for the Proxool support.

Now I've never used c3po or DBCP, but can someone point out what our 
differences incase they ask.

Martin