proxool-developer — Developer's discussion list

[Proxool-developer] DocBook (Was: Proxool 0.6)

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

> Ok so I think the first part is to port the content into DocBook format.
> We can then look at the stylesheet and integration into the web site.

I agree.

> Before begining the port we need to determine the structure of the
> DocBook files. One of the problems of what you're doing is that DocBook
> really emphasises document structure and is not setup to specifically
> support web site content.
>
> Having said that, most of the web site is content documentation so I
> think we can come up with a solution.
>
> On first inspection I see two main documents "Users Guide" and
> "Developers Guide". Additionally, I see two articles "Quick Start" and
> "FAQ". I think we focus on porting these pages over. Everything else is
> really web site specific and should probably remain as part of the web
> site (the change log could be grabbed from somewhere else, and the
> requirements should probably be in the users guide).

I agree on your classification of the main documents. What is now called
"Documentation" in the web site really is the user guide, and what is called
"Developers" is the developers guide. They are both documentation.

but.. i think the structure of the whole web site could fit into a <book>
with the different menu items as <chapters>s (see example fragment on the
bottom of the mail.

...or maybe the main documents ought to be separate <book>s?

It wold be really nice to have *all* the Proxool information elements in a
media independent format, and under version control. <chapter>s (or
<books>s) that are spesific to a certain presentation format could be
classified with a role attribute (i.e. <chapter role="web">...</chapter>) to
help style sheets determine what elements are relavent for them.

> I think the Java/Struts app will need to just bind all these various
> pages together and provide the web site specific things such as side bar
> nav, source forge link and home page.

The side bar and that could easily be constructed by the web site style
sheet so we don't need to represent them in our xml. I think we won't need
the Struts dependency.

> A Am I making sense, this is all before a morning coffee;)

Absolutely. I'm writing this way after bed time, so forgive any logical
breaches ;)

Anyways. As you say, the important thing now is to create the DocBook xml.
If you decide to do the two main documents first we can always add the other
stuff later.

I'd be happy to have a go at the web site style sheet at a later stage.

Heres the example DocBook fragment:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE set SYSTEM "C:\Files\lib\xml\docbook-xml-4.2\docbookx.dtd">
<set>
  <book>
    <title>Proxool</title>
    <chapter>
      <beginpage/>
      <title>Quick Start</title>
      <sect1>
        <title/>
        <para>
          This document describes how to invoke Proxool. It assumes that
you're
          familiar with the Java language in general and the JDBC API in
particular.
          Please visit Sun's JDBC web site for information about JDBC.
        </para>
        <para>
          Take the following steps to invoke Proxool:
        </para>
      </sect1>
      <sect1>
        <title>Load the Proxool driver</title>
        <para>
          Make sure that the Proxool JAR file is available in the classpath
of your
          Java Runtime Environment and load the Proxool JDBC Driver:
          <programlisting>
            Class.forName("org.logicalcobwebs.proxool.ProxoolDriver");
          </programlisting>
        </para>
      </sect1>
      <sect1>
        <title>Define the URL</title>
        ...
      </sect1>
    </chapter>
    <chapter>
      <beginpage/>
      ...
    </chapter>
  </book>
</set>

CHR

[Proxool-developer] Cipherware & Proxool

[Bas C. <ba...@ci...>]

Dear list,

As you might have noticed we haven't posted for a while. The reason for 
this is the fact that we're preparing a release of our product which is 
way past due. We try to resume our work on Proxool shortly; in the mean 
time we will watch the list closely.

Kind regards,
Bas

-- 
Bas Cancrinus   -> ba...@ci...
Software Architect
Cipherware Ltd. -> http://www.cipherware.com

Re: [Proxool-developer] DocBook Web Site

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

All.

Ok so I think the first part is to port the content into DocBook format.
We can then look at the stylesheet and integration into the web site.

Before begining the port we need to determine the structure of the
DocBook files. One of the problems of what you're doing is that DocBook
really emphasises document structure and is not setup to specifically
support web site content.

Having said that, most of the web site is content documentation so I
think we can come up with a solution.

On first inspection I see two main documents "Users Guide" and
"Developers Guide". Additionally, I see two articles "Quick Start" and
"FAQ". I think we focus on porting these pages over. Everything else is
really web site specific and should probably remain as part of the web
site (the change log could be grabbed from somewhere else, and the
requirements should probably be in the users guide). 

I think the Java/Struts app will need to just bind all these various
pages together and provide the web site specific things such as side bar
nav, source forge link and home page. 

Am I making sense, this is all before a morning coffee;)
Martin

[Proxool-developer] New Developer

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

Martin Crawford (musicstar) has joined the Proxool developer team. He'll
be working on converting the documentation to DocBook format. We now
have five developers: Bas, Christian, Gard, Martin and me.

-- 
Bill Horsman
  Logical Cobwebs Limited
  http://www.logicalcobwebs.co.uk
  ICQ: 119577180

Re: [Proxool-developer] Proxool 0.6

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

Martin and Christian,

Some background on the DocBook task:

The web site is actually produced in a number of different flavours at
the moment.

1. The online (proxool.sourceforge.net) version contains all pages and
uses a version of the SourceForge logo that acts as a counter for the
site. It contains a "side box" that says something like "the latest
version of Proxool is 0.6".

2. The source distrubution contains all pages except the download page
(for obvious reasons), and the counter is inactive. It contains a "side
box" that says something like "you can get the latest version from the
web site".

3. The binary distrubution is like the source distribution but it lacks
all the developer pages (which tell you how to build the source etc.).

> We can have a go at other formats (like a documentation PDF) later. 

Sure :)

At the moment, I produce the web site from a JSP/Struts app. I don't
think there is any benefit in making this available to you - all the
content is available on the web site. 

Bill

Re: [Proxool-developer] Proxool 0.6

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

> I am familiar with DocBook, and would be willing to perform some
> monotonous cut 'n paste. Additionally, I can easily pull together the
> Ant tasks to handle validation and stylesheeting. If you want an extra
> hand I'd be happy to help.

Great :)

I have several other tasks to attend to, so I'll happily pass this one over to you. Please let me know if you want me to do anything.

> What exactly is the goal: take the documentation and structure it into a
> DocBook format, or the entire web site?

Entire website. At a later stage we can write a stylesheet that extracts the pure documentation only.

> Is there a stylesheet ready to
> generate the HTML or are you planning to use and/or modify the
> Norm-blessed XSLT package?

We have no stylesheet, and we were planning to write a stylesheet that produces the website (as it is today) first. 

There are some differences between the online site and the site in the distribution. Details Bill?

We can have a go at other formats (like a documentation PDF) later. 

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] Proxool 0.6

[Martin C. <mar...@sy...>]

> 3. Possibly, if Christian finds time, convert the documentation (in
> other words, the web site) into DocBook format and create a new project
> that contains it. This will give all the developers the opportunity to
> contribute to the doc without going through me.

I am familiar with DocBook, and would be willing to perform some
monotonous cut 'n paste. Additionally, I can easily pull together the
Ant tasks to handle validation and stylesheeting. If you want an extra
hand I'd be happy to help.

What exactly is the goal: take the documentation and structure it into a
DocBook format, or the entire web site? Is there a stylesheet ready to
generate the HTML or are you planning to use and/or modify the
Norm-blessed XSLT package?

Martin

[Proxool-developer] Proxool 0.6

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

Hi all,

Proxool 0.6 has finally broken free :) It took a little longer than I
expected but there it is. See the change log for a list of the many
changes.

0.7 is coming soon with:

1. J2EE compliance. I hope. If we remove the code that uses System
properties. I'm hoping Bas and Alastair are going to help with the
testing of that.

2. Clean up of the listener code (we have three listeners:
ConfigurationListenerIF, ConnectionListenerIF, and StateListenerIF). At
the moment you are only allowed one listener per pool which is a bit
limiting.

3. Possibly, if Christian finds time, convert the documentation (in
other words, the web site) into DocBook format and create a new project
that contains it. This will give all the developers the opportunity to
contribute to the doc without going through me.

4. Fix for DatabaseMetaData giving you the delegate Connection rather
than the Proxool one.

5. Maybe a look at JDK 1.2 again. I notice that 25% or people downloaded
the JDK 1.2 version of release 0.4. That's surprised me. the JDK 1.2
code has been static since then and it doesn't get tested for each
release. I think maybe it should be. The long term plan here is to
provide a 1.2 version of release 1.0 and then branch it. From then on
JDK 1.2 will be maintenance only.

Regards,
--
Bill Horsman
  Logical Cobwebs Limited
  http://www.logicalcobwebs.co.uk
  ICQ: 119577180

[Proxool-developer] Proxool 0.6 Release Candidate

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

Hi all,

I have just posted a release candidate of Proxool 0.6. You can see the
web site here:

  http://proxool.sourceforge.net/dev

I've made quite a few changes to the web site. Christian is planning to
convert the web site (currently a JSP web app) into DocBook sometime
soon so that we can easily contribute stuff by CVS.

The change log is:

0.6 - January 23, 2003 

- ProxoolFacade API has changed slightly. Some of the methods no longer
throw an SQLException but a ProxoolException instead. This might lead to
some small changes in your code. 

- There used to be some ambiguity about whether you referred to a pool
by its alias or its full url (when using ProxoolFacade). This has now
been fixed. This means you can now change the url (to use a different
database for instance) without creating a new pool. 

- Version information is now logged so you can tell what version of
Proxool you are using. 

- ConnectionPoolStatisticsIF now reports the time the pool was started. 

- We now use FastArrayList (from Jakarta Commons) instead of the JDK's
Vector for improved collection support. 

- New JAXPConfigurator and PropertyConfigurator to make it easy to
configure proxool from a file. 

- New ConfigurationListenerIF interface allows you to implement a
persistent configuration. 

- Bug fix for JDBC drivers that implement the Statement interface
indirectly (that is, extend a class that implements it rather than
implementing it directly). (Credit to Martin Crawford). 

- Unclosed Statements are now automatically closed when the Connection
is closed, in accordance with the JDBC spec. 

- Rollback is called on all connections when they are closed (that is,
returned to the pool). This has no effect if autoCommit it true
(default) or any pending transactions have been committed or already
rolled back. This will only have an effect if you currently close
connections with pending transactions. 

- ProxoolFacade's new getDelegateStatement allows you to get to the
underlying JDBC Driver's original Statement if you really need to. (This
isn't recommended unless you have no other choice). 

- You can now update the URL for a pool, not just the properties. See
ProxoolFacade's updateConnectionPool.

---

I hope to make a final release tomorrow, depending on the feedback I get
from this.

Happy Proxooling!
Bill

Re: [Proxool-developer] J2EE Compliance and System Properties

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

Martin,

On Wed, 2003-01-22 at 14:21, Martin Crawford wrote:

> Your other email spoke of testing, and this one relates (I believe) to a
> fix made for the Tomcat Servlet container issues I experienced. Not sure
> how you could write a test case for this, but again I would be will to
> drop it into our web app to see if it gets undeployed properly.

Even if it is not an automated junit test, a manual test would be very
welcome thank you. Just to be clear, we are releasing 0.6 any day now
(maybe tomorrow) but the System properties won't be removed until 0.7.
I'll produce a snapshot as soon as we are ready to test and let you
know.

(Good to hear from you again in 2003, Martin)

Bill

[Proxool-developer] Testing

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

Hi all,

I think we do a pretty good job on testing (the junit tests we have),
but it can be improved. We have 25 tests just now but I am on the look
out for other characteristics to test. If anyone gets any ideas then
speak up and we'll add them.

Bill

[Proxool-developer] J2EE Compliance and System Properties

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

Hi all,

FYI:

Christian is about to start work on removing the (only recently added!)
ReloadMonitor (which makes use of System Properties to detect
application reload). Chr, can you do a quick test to see in what
circumstances the finalize() method gets called? 

Bill

[Proxool-developer] 0.6 Delayed by a few days

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

Hi all,

In conversation with Christian this afternoon, I have decided to
postpone 0.6 until next week to allow inclusion of the ProxoolException
refactoring. This will break backwards compatability (you'll now have to
catch ProxoolExceptions instead of SQLExceptions in some instances) and
we felt that this should be done as early as possible.

So 0.6 will include that along with clarification of the use of url,
alias and poolName in some of the APIs (I've nearly finished that
anyway).

Bill

[Proxool-developer] 0.6!

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

Hi all,

It's been a little quite over Christmas (on the Proxool front at least),
so I'm now kicking off 2003 with a new release of Proxool.

Actually, it's still a hidden release but you can find it at
http://proxool.sourceforge.net/dev

If I don't get any complaints (like: "the download doesn't include the
source code, dummy!") in the next 24 hours or so I'll make the release
public.

One of the latest fixes was to swap the internal Vector that stored the
connections for a FastArrayList copied from Jakarta Commons. The reason
for this was that the agentprovocateur.com site was reporting some
innaccurate statistics which, although not critical, was worrying. I
think this will fix it.

There's still lots of stuff that I'm working on right now... but I
wanted to make a release to keep the momentum going. In the pipeline:

1. Review of use of alias and url in the ProxoolFacade API to make it
unambiguous. (I'll probably make it mandatory to define an alias).

2. Introduction of ProxoolException to ProxoolFacade API instead of use
of RuntimeException and SQLException when it isn't appropriate.

3. Removal of System properties stuff to conform to J2EE spec. This
means junking the ReloadMonitor and adding documentation advising people
to destroy pools in their web apps destroy process (as far as I know,
this is only an issue for web apps). 

4. Well, three things in the pipeline will do for now.


Sorry this release has been delayed. It's been a combination of
Christmas, a bizarre reluctance to work into the night, a lack of child
care (fixed now), and illness (also fixed). Onwards with 0.7!

Bill

RE: [Proxool-developer] Cleaning up transactions

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

> Reflecting the above statement to Proxool, ConnectionResetter.reset(...)
> should
> a) detect whether a transaction is in progress;
> b) if a) is true then call Connection.rollback();
> c) call connection.setAutoCommit(true).
>
> Avoiding a) should be harmless, so just calling Connection.rollback();
> connection.setAutoCommit(true); will do.

Without looking at the code carefully, might I suggest proxool tracker the
life of a transaction (and satisfy the requirements of a) based on the
autoCommit flag and whether statements have been executed with
commit()/rollback() subsquently called (or not called) before
Connection.close(). This might avoid potential poorly written JDBC drivers
getting bunged up if rollback() is called without an active transaction.

I agree also that maybe shouldn't be be proxool's concern. Additionally, I
agree that proxool might be having to assume too much to track a
transaction, which coul be dangerous. I really just thought I'd throw it out
there for you guys to think about.

Otherwise, this does sound like the most reasonable approach. Incidentally,
on my servlet application I made a facade database pool with proxool just
underneath. When my developers physically "return" the database connection
and before I call Connection.close() I rollback() blindly, catching any
exceptions. This has been working without incident, and should validate what
you are proposing.

Cheers.
Martin

Re: [Proxool-developer] When will 0.6 be released?

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

On Sat, 2002-12-21 at 04:30, Bas Cancrinus wrote:

> When is Proxool 0.6 expected to be released?

It was planned for 20 December but I'm running a bit behind schedule. We
are ready for release as soon as:

1) Christian, are you through with the configuration changes?

2) Alastair, are you planning any compliance tests (with the new
automatic statement closing)?

3) Everyone, what is the feeling about Bas's proposal to automatically
rollback all connections upon reset? (This will only have an effect on
transactions that have been committed and where autoCommit is false). I,
for one, think it's a good idea.

When we get these three questions answered then I think we can release
0.6. There are a few things that I was hoping to get into 0.6 that we
should perhaps leave until 0.7. They are: 

4) Review of alias/url and its impact when you switch the url for an
existing pool.

5) Refactoring of ProxoolFacade to throw ProxoolException where existing
SQLExceptions and RuntimeExceptions are inappropriate. 

---

I think a lot of us will be affected by the approaching holiday season.
I would otherwise expect to release in the next 2-3 days. As it is, I
predict anytime between Dec 27 and Jan 3.

Regards,
Bill

Re: [Proxool-developer] Cleaning up transactions

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

On Sat, 2002-12-21 at 04:18, Bas Cancrinus wrote:

> Reflecting the above statement to Proxool, ConnectionResetter.reset(...) 
> should
> a) detect whether a transaction is in progress;
> b) if a) is true then call Connection.rollback();
> c) call connection.setAutoCommit(true).
> 
> Avoiding a) should be harmless, so just calling Connection.rollback(); 
> connection.setAutoCommit(true); will do.

Sounds sensible to me.

Regards,
Bill

[Proxool-developer] When will 0.6 be released?

[Bas C. <ba...@ci...>]

Hi,

When is Proxool 0.6 expected to be released?

Thanks,
Bas

-- 
Bas Cancrinus   -> ba...@ci...
Software Architect
Cipherware Ltd. -> http://www.cipherware.com

[Proxool-developer] Forgot the reference

[Bas C. <ba...@ci...>]

[1] Database Language SQL (Proposed revised text of DIS 9075), 
       July 1992 - http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt

-- 
Bas Cancrinus   -> ba...@ci...
Software Architect
Cipherware Ltd. -> http://www.cipherware.com

Re: [Proxool-developer] Cleaning up transactions

[Bas C. <ba...@ci...>]

Bill Horsman wrote:
> I couldn't find any documentation on what a JDBC Driver should do when a
> Connection is closed whilst a transaction is in process. If anyone finds
> anything that would dictate what we should do then I would be happy to
> adopt that. Perhaps we could do some empirical testing of some of the
> drivers and see what they do. Even then, I would hesitate to adopt
> something that wasn't specified.

Regarding a call to Connection.close() while a transaction is in 
progress as an 'unrecoverable error' satisfies the following statement:

"The execution of a <rollback statement> may be initiated implicitly by 
an implementation when it detects unrecoverable errors. When such an 
error occurs, an exception condition is raised: transaction rollback 
with an implementation-defined subclass code" [1].

>>Should proxool, perhaps be forcing a commit or rollback? Perhaps this should
>>be a property setting to commit or rollback as a default once closed?
> That's a matter of debate. I would suggest that it isn't really our job.
> I would rather guide people into using a less ambiguous approach:
> namely, always calling commit or rollback.

Reflecting the above statement to Proxool, ConnectionResetter.reset(...) 
should
a) detect whether a transaction is in progress;
b) if a) is true then call Connection.rollback();
c) call connection.setAutoCommit(true).

Avoiding a) should be harmless, so just calling Connection.rollback(); 
connection.setAutoCommit(true); will do.

BTW: I consider implied commits very dangerous and I'm surprised that 
Connection.setAutoCommit(true) doesn't throw an SQLException if a 
transaction is in progress.

Regards,
Bas

-- 
Bas Cancrinus   -> ba...@ci...
Software Architect
Cipherware Ltd. -> http://www.cipherware.com

Re: [Proxool-developer] J2EE 1.2.1 compliance testing

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

Alastair,

I have just committed the changes for automatic Statement closing. Any
Statements that remain open when the Connection is closed are closed
automatically. There is a debug message too.

I hope this helps the compliance testing.

Regards,
Bill

[Proxool-developer] Aliases and URLs

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

Hi all,

I've been thinking about our use of aliases and URLs. A lot of the
methods on ProxoolFacade accept an alias to define the pool and some
accept the full URL. Most of them will actually, behind the scenes,
accept both. This is confusing (for users and developers alike).

I propose that we specify the use of aliases on all occassions. We can
provide a helper method that will extract the alias from a URL.

One of the requirements is that people should be able to switch to
Proxool simply by changing the URL that they use. So the methods
provided by java.sql.Driver should accept both the URL and the alias. In
other words: 

public Connection connect(String url, Properties info) 

should always be the full url, like: 
    proxool.apple:org.hsqldb.jdbcDriver:jdbc:hsqldb:test

Whereas ProxoolFacade#getConnectionInfos(String alias), for instance,
should always take the alias, like:
    apple

It all comes to a head in the ConnectionManager where it stores a map to
every conneciton using *three* keys (in our example:
"proxool.apple:org.hsqldb.jdbcDriver:jdbc:hsqldb:test", "proxool.apple",
and "apple"). This is bad.

Another point is that Gard at Findexa is writing some code that allows
you to switch URLs for an active pool (to point at a different
database). If you do this then the URL is no longer a constant key. Hmm.

If we think this is a good idea then we have to think of a way of
introducing that change without breaking peoples code. One way would be
to introduce new method names and deprecate the old ones. Disadvantages:
1) we have to pick names that possibly aren't ideal and we'd be stuck
with, 2) we have to maintain the old code for a while anyway with a view
to dropping it before 1.0 anyway. Advantages: 1) Anybody downloading the
latest code still has a working app.



What do you think?

Bill

Re: [Proxool-developer] Cleaning up transactions

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

Martin,

On Wed, 2002-12-18 at 20:32, Martin Crawford wrote:

> Just some questions about proxool and transaction maintenance is once a
> connection closed. Upon quick inspection of the source, I see that the
> close/cleanup procedure calls the setAutoCommit(true) the comment: "Setting
> autoCommit to true might well commit all pending transactions. But that's
> beyond our control." Does this imply that JDBC drivers are mandated to reset
> the transaction, commit it, or just do whatever they feel is best?

We've agonised a lot over this and haven't taken the decision lightly.
To justify resetting autoCommit to true imagine the situation where two
separate components share the same pool and the first one leaves
autoCommit as false (which is perfectly acceptable, at least in theory).
Then the second one gets a Connection and wonders why nothing actually
gets committed. This is the sort of error that won't crop up in unit
testing and could be a real devil to track down. That's exactly what we
want to avoid.

Our aim is to hand out connections as if they were new. But it turns out
that that is an impossible task and we have to make some assumptions.

I couldn't find any documentation on what a JDBC Driver should do when a
Connection is closed whilst a transaction is in process. If anyone finds
anything that would dictate what we should do then I would be happy to
adopt that. Perhaps we could do some empirical testing of some of the
drivers and see what they do. Even then, I would hesitate to adopt
something that wasn't specified.

> Is this the only transaction maintenance performed?

The ConnectionResetter class resets the following properties:

autoCommit
catalog
readOnly
transactionIsolation
typeMap
holdability

> Should proxool, perhaps be forcing a commit or rollback? Perhaps this should
> be a property setting to commit or rollback as a default once closed?

That's a matter of debate. I would suggest that it isn't really our job.
I would rather guide people into using a less ambiguous approach:
namely, always calling commit or rollback.

> Additionally, I could not find anything in the JDBC API about determining if
> a transaction is currently running, anyone know anything?

Yes, that would be nice. Then we could log a warning. 

We have three goals here (in order of importance):

1. Using Proxool should behave exactly the same way as using the
delegate driver (only faster).

2. The state of a Connection from the pool should not be dependent on
how another component returns it.

3. Closing a Connection in an ambiguous state should react the same way
as closing the delegate Connection.

It would seem that we are possibly failing on point 3 at the moment. I
don't think configuration of commit() or rollback() is the answer. I
hope. 

> Just some more details from the field.

Keep it coming.

If anyone can report on how their particular JDBC driver handles
ambiguous closes (autoCommit is false, no commit or rollback) then that
might give us an indication of what we should be doing. Certainly, if
all common drivers perform a commit and Proxool does a rollback then at
the very least we should be documenting that behaviour.

A Connection Pool turns out to be a lot more complicated than I thought
:)

Bill

[Proxool-developer] Cleaning up transactions

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

All.

Just some questions about proxool and transaction maintenance is once a
connection closed. Upon quick inspection of the source, I see that the
close/cleanup procedure calls the setAutoCommit(true) the comment: "Setting
autoCommit to true might well commit all pending transactions. But that's
beyond our control." Does this imply that JDBC drivers are mandated to reset
the transaction, commit it, or just do whatever they feel is best?

Is this the only transaction maintenance performed?

Should proxool, perhaps be forcing a commit or rollback? Perhaps this should
be a property setting to commit or rollback as a default once closed?
Granted doing the commits and rollbacks is really required diligence on the
programmer, but one stray transaction could really mess up consistency and
block other transactions on the database.

Additionally, I could not find anything in the JDBC API about determining if
a transaction is currently running, anyone know anything?

Just some more details from the field.
Martin

Re: [Proxool-developer] J2EE 1.2.1 compliance testing

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

On Sun, 2002-12-15 at 14:24, Alastair Calderwood wrote: 

> Out of interest has anyone else had this 
> problem with the jar, or are you all using unjarred classes?  I'll use 
> them unjarred until this problem is solved.

I always test with unjarred classes...

> Cursors are staying open only because the test suite does 
> not close every PreparedStatement but instead relies on the close method 
> of Connection, which with a plain driver (i.e. without a connection pool 
> in front) would call finalize on the whole hierarchy.  In a connection 
> pool where connections are not really closed, and there is no reference 
> to the hierarchy, this never occurs.  Personally I'd say it was the 
> application programmer's responsiblity to close PreparedStatements - not 
> sure why they haven't done so in the tests - and in my opinion the 
> failure of these tests is not too important, but others might have 
> different points of view.  

I was chatting with Christian on ICQ last night (btw, my ICQ is
119577180) and we decided to get the ProxyConnection to close all
unclosed Statements when it closes. We can write a debug message to the
log to say that we are closing it for the user. This will be easy
enough.

On Sun, 2002-12-15 at 22:51, Bas Cancrinus wrote:

> Perhaps there are cases when a lazy close() is more efficient then 
> closing each resource immediately after usage (??)

Don't know exactly what you mean by lazy close, but I suspect it's very
similar to closing automatically during the ConnectionReset method that
I'm proposing.

---

Thanks for all your work on the compliance testing, Alastair. I think
I'm right in thinking that if we fix the Statement closure and the JAR
file thing we will have passed?

Regards,
Bill