[jira] Updated: (DBCP-28) [dbcp][PATCH] Connection leak in PoolableConnection.close() (Oracle 10g driver)

2006-07-12 Thread Philippe Mouawad (JIRA) 
 [ http://issues.apache.org/jira/browse/DBCP-28?page=all ]

Philippe Mouawad updated DBCP-28:
-

Attachment: 
ShowsBasicDataSourceBadNumActiveIfNoCheckForIsClosedAndDoubleClose.java
ShowsLeaksIfCheckForIsClosed.java
TestUtils.java

Hello,
The files contain an illustration of the problem that will occur when the the 
previous patches will be applied in 1.2.2:
Case 1:
The client calls isClosed() before closing a connection since commons-dbcp does 
not allow double close without throwing (see 
http://issues.apache.org/jira/browse/DBCP-3)
= The problem is that since he calls isClosed, he encounters the same bug 
reported here because conn.isClosed() will return true and the client will not 
call close.
if (!conn.isClosed())
{
try{
conn.close();
}catch(Exception e){}
}
see what happens if the isClosed() in PoolableConnection returns true : 
ShowsLeaksIfCheckForIsClosed

Case2:
The client tries to find a solution, and calls conn.close() without checking 
isClosed(), but the problem is that the client is in a Persistence fwk and the 
client may have already called close, so he ends up calling close() twice, see 
what happens if the isClosed() in PoolableConnection returns true : 
ShowsBasicDataSourceBadNumActiveIfNoCheckForIsClosedAndDoubleClose

So My question is, what can I do if the double close is not allowed by DBCP

 [dbcp][PATCH] Connection leak in PoolableConnection.close() (Oracle 10g 
 driver)
 ---

  Key: DBCP-28
  URL: http://issues.apache.org/jira/browse/DBCP-28
  Project: Commons Dbcp
 Type: Bug

 Versions: 1.2 Final
  Environment: Operating System: All
 Platform: PC
 Reporter: Dirk Verbeeck
  Fix For: 1.2.2
  Attachments: PoolableConnection.patch, 
 ShowsBasicDataSourceBadNumActiveIfNoCheckForIsClosedAndDoubleClose.java, 
 ShowsLeaksIfCheckForIsClosed.java, TestPoolableConnection.patch, 
 TestUtils.java

 Mail from Hugh Winkler on commons-dev (15-2-2005)
 --
 PoolableConnection.close() does logic equivalent to :
   if ( isClosed()){
   throw new SQLException(.);
   } else {
   _pool.returnObject(this);
   }
 The isClosed() method is that of ancestor DelegatingConnection, and it does:
   if(_closed || _conn.isClosed()) {
   return true;
   }
   return false;
 Now nothing prevents the underlying connection from closing itself; that's
 why isClosed() checks _conn.isClosed() -- did you close yourself while I
 wasn't looking? But in that case PoolableConnection never calls
 _pool.returnObject(). 
 I've got a query in Oracle 10g that causes Oracle's connection to close
 itself: the famous end of file on connection message causes the connection
 to enter the closed state. Doesn't take long to exhaust the pool.
 I think the logic we want in PoolableConnection.close() is like so:
   if ( _closed ){ // really ask, did *we* close the connection already
   throw new SQLException(.);
   } else {
   _pool.returnObject(this);
   }
 If I've got some logic wrong please stop me before I deploy that change
 here!

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (DBCP-3) [dbcp] PoolableConnection.close() won't allow multiple close

2006-07-12 Thread Philippe Mouawad (JIRA) 
[ http://issues.apache.org/jira/browse/DBCP-3?page=comments#action_12420734 
] 

Philippe Mouawad commented on DBCP-3:
-

See Comment of [Philippe Mouawad] 12/Jul/06 09:19 PM for a problem that occurs 
if this bug is not corrected.
http://issues.apache.org/jira/browse/DBCP-28

Philippe.

 [dbcp] PoolableConnection.close() won't allow multiple close
 

  Key: DBCP-3
  URL: http://issues.apache.org/jira/browse/DBCP-3
  Project: Commons Dbcp
 Type: Bug

 Versions: Nightly Builds
  Environment: Operating System: All
 Platform: All
 Reporter: Adam Jenkins
  Fix For: 1.3


 Sun's javadoc for java.sql.Connection.close() specifies that calling close on 
 an
 already closed Connection is a no-op.  However, PoolableConnection.close() (v
 1.10) throws a SQLException if close() is called on a closed Connection. 
 PoolableConnection.close() should just return if the Connection is already
 closed.  Here is a patch:
 To demonstrate the bug, just obtain an open PoolableConnection and call 
 close()
 on it twice; the second call will produce a SQLException.  According to Sun's
 spec, the second close() should just be a no-op.  The current behaviour is
 preferable to the old behaviour where it returned the Connection to the pool
 twice, but it's still not according to the spec.
 Here's a patch:
 *** PoolableConnection.java.orig2003-09-15 16:07:53.0 -0400
 --- PoolableConnection.java 2003-09-15 16:08:11.0 -0400
 ***
 *** 108,114 
*/
public synchronized void close() throws SQLException {
   if(isClosed()) {
 ! throw new SQLException(Already closed.);
   } else {
   try {
   _pool.returnObject(this);
 --- 108,114 
*/
public synchronized void close() throws SQLException {
   if(isClosed()) {
 ! return;
   } else {
   try {
   _pool.returnObject(this);

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (DBCP-193) BasicDataSource returns negative values for NumActive when Oracle Driver Connection#isClosed return true (End of file communication on CHannel)

2006-07-12 Thread Philippe Mouawad (JIRA) 
BasicDataSource returns negative values for NumActive when Oracle Driver 
Connection#isClosed return true (End of file communication on CHannel)
---

 Key: DBCP-193
 URL: http://issues.apache.org/jira/browse/DBCP-193
 Project: Commons Dbcp
Type: Bug

Versions: 1.2.1, 1.2.2
 Environment: Windows / Oracle 10G JDBC driver / Oracle 10G / JDK 1.4.2_08 / 
Commons-dbcp-1.2.1.jar / COmmons-pool-1.3.jar
Reporter: Philippe Mouawad
Priority: Blocker


Hello,
This bug occurs if the following conditions are met:
A End of File communication on CHannel occurs 
Oracle Driver 10G will return true for Connection#isClosed()

Related bugs:
http://issues.apache.org/jira/browse/DBCP-3
http://issues.apache.org/jira/browse/DBCP-28

Case 1:
The client calls isClosed() before closing a connection since commons-dbcp does 
not allow double close without throwing (see 
http://issues.apache.org/jira/browse/DBCP-3)
= The problem is that since he calls isClosed, he encounters the same bug 
reported in http://issues.apache.org/jira/browse/DBCP-28 because 
conn.isClosed() will return true and the client will not call close.
if (!conn.isClosed())
{
try{
conn.close();
}catch(Exception e){}
}
see what happens if the isClosed() in PoolableConnection returns true : 
ShowsLeaksIfCheckForIsClosed.java

Case2:
The client tries to find a solution, and calls conn.close() without checking 
isClosed(), but the problem is that the client is in a Persistence fwk and the 
client may have already called close, so he ends up calling close() twice, see 
what happens if the isClosed() in PoolableConnection returns true : 
ShowsBasicDataSourceBadNumActiveIfNoCheckForIsClosedAndDoubleClose.java


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (DBCP-193) BasicDataSource returns negative values for NumActive when Oracle Driver Connection#isClosed return true (End of file communication on CHannel)

2006-07-12 Thread Philippe Mouawad (JIRA) 
 [ http://issues.apache.org/jira/browse/DBCP-193?page=all ]

Philippe Mouawad updated DBCP-193:
--

Attachment: 
ShowsBasicDataSourceBadNumActiveIfNoCheckForIsClosedAndDoubleClose.java
ShowsLeaksIfCheckForIsClosed.java
TestUtils.java

To work, the call isClosed() in PoolableConnection.java must return true (Case 
of an End of communication on channel in Oracle):
public synchronized void close() throws SQLException {
boolean isClosed = false;
try {
isClosed = isClosed();

 BasicDataSource returns negative values for NumActive when Oracle Driver 
 Connection#isClosed return true (End of file communication on CHannel)
 ---

  Key: DBCP-193
  URL: http://issues.apache.org/jira/browse/DBCP-193
  Project: Commons Dbcp
 Type: Bug

 Versions: 1.2.1, 1.2.2
  Environment: Windows / Oracle 10G JDBC driver / Oracle 10G / JDK 1.4.2_08 / 
 Commons-dbcp-1.2.1.jar / COmmons-pool-1.3.jar
 Reporter: Philippe Mouawad
 Priority: Blocker
  Attachments: 
 ShowsBasicDataSourceBadNumActiveIfNoCheckForIsClosedAndDoubleClose.java, 
 ShowsLeaksIfCheckForIsClosed.java, TestUtils.java

 Hello,
 This bug occurs if the following conditions are met:
 A End of File communication on CHannel occurs 
 Oracle Driver 10G will return true for Connection#isClosed()
 Related bugs:
 http://issues.apache.org/jira/browse/DBCP-3
 http://issues.apache.org/jira/browse/DBCP-28
 Case 1:
 The client calls isClosed() before closing a connection since commons-dbcp 
 does not allow double close without throwing (see 
 http://issues.apache.org/jira/browse/DBCP-3)
 = The problem is that since he calls isClosed, he encounters the same bug 
 reported in http://issues.apache.org/jira/browse/DBCP-28 because 
 conn.isClosed() will return true and the client will not call close.
 if (!conn.isClosed())
 {
 try{
 conn.close();
 }catch(Exception e){}
 }
 see what happens if the isClosed() in PoolableConnection returns true : 
 ShowsLeaksIfCheckForIsClosed.java
 Case2:
 The client tries to find a solution, and calls conn.close() without checking 
 isClosed(), but the problem is that the client is in a Persistence fwk and 
 the client may have already called close, so he ends up calling close() 
 twice, see what happens if the isClosed() in PoolableConnection returns true 
 : ShowsBasicDataSourceBadNumActiveIfNoCheckForIsClosedAndDoubleClose.java

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[PATCH] digester XML (call-param-rule)

2002-10-07 Thread Philippe Mouawad 

I found a bug in the digester.
It happens when you use the rules written in xml
instead of writing them in the code (see code below).
The bug happens when you use call-param-rule / in
the xml file.

try
{
FileInputStream fis = new
FileInputStream(configFileName);
// the file config-rules.xml contains rules written 
//in xml
URL url = getClass().getResource(config-rules.xml);
BatchContext config =  (BatchContext) 
DigesterLoader.load(url, getClass().getClassLoader(),
fis, this);
fis.close();
}
catch(DigesterLoadingException dle)
{
throw new BatchException(dle);   
}
catch (SAXException ioe)
{
ioe.printStackTrace();
throw new BatchException(ioe);
}
catch (IOException ioe)
{
throw new BatchException(ioe);
}
 


___
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com

public void addRuleInstances(Digester digester) {
final String ruleClassName = Rule.class.getName();
digester.register(DIGESTER_PUBLIC_ID, getDigesterRulesDTD());

digester.addRule(*/pattern, new PatternRule(digester, value));

digester.addRule(*/include, new IncludeRule(digester));

digester.addFactoryCreate(*/call-method-rule, new CallMethodRuleFactory());
digester.addRule(*/call-method-rule, new PatternRule(digester, pattern));
digester.addSetNext(*/call-method-rule, add, ruleClassName);

 
//
//
// Modified by Philippe Mouawad
//

digester.addFactoryCreate(*/call-param-rule, new CallParamRuleFactory());
digester.addRule(*/call-param-rule, new PatternRule(digester, pattern));
digester.addSetNext(*/call-param-rule, add, ruleClassName);

//
// End of modification
//
 
//

digester.addFactoryCreate(*/factory-create-rule, new 
FactoryCreateRuleFactory());
digester.addRule(*/factory-create-rule, new PatternRule(digester, 
pattern));
digester.addSetNext(*/factory-create-rule, add, ruleClassName);

digester.addFactoryCreate(*/object-create-rule, new 
ObjectCreateRuleFactory());
digester.addRule(*/object-create-rule, new PatternRule(digester, pattern));
digester.addSetNext(*/object-create-rule, add, ruleClassName);

digester.addFactoryCreate(*/set-properties-rule, new 
SetPropertiesRuleFactory());
digester.addRule(*/set-properties-rule, new PatternRule(digester, 
pattern));
digester.addSetNext(*/set-properties-rule, add, ruleClassName);

digester.addRule(*/set-properties-rule/alias, new 
SetPropertiesAliasRule(digester));

digester.addFactoryCreate(*/set-property-rule, new SetPropertyRuleFactory());
digester.addRule(*/set-property-rule, new PatternRule(digester, pattern));
digester.addSetNext(*/set-property-rule, add, ruleClassName);

digester.addFactoryCreate(*/set-top-rule, new SetTopRuleFactory());
digester.addRule(*/set-top-rule, new PatternRule(digester, pattern));
digester.addSetNext(*/set-top-rule, add, ruleClassName);

digester.addFactoryCreate(*/set-next-rule, new SetNextRuleFactory());
digester.addRule(*/set-next-rule, new PatternRule(digester, pattern));
digester.addSetNext(*/set-next-rule, add, ruleClassName);
}


protected class CallParamRuleFactory extends AbstractObjectCreationFactory {

// Old code
//public Object createObject(Attributes attributes) {
//// create callmethodrule
//int paramNumber = Integer.parseInt(attributes.getValue(paramnumber));
//String methodName = attributes.getValue(attrname);
//Rule callMethodRule = new CallMethodRule(targetDigester, methodName,
//paramNumber);
//return callMethodRule;
//}
// End of old code

 
//
//
// Modified by Philippe Mouawad
//
//
// Modified by Philippe Mouawad
//
public Object createObject(Attributes attributes) {
// create callmethodrule
int paramNumber = Integer.parseInt(attributes.getValue(paramnumber));
String attrName = attributes.getValue(attrname);
Rule callParamRule = new CallParamRule(targetDigester, paramNumber, 
attrName);
return callParamRule ;
}

//
// End of modification
//
 
//

}


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]