reallyClose
method so it only checks the real connection before closing.
-dain
--
View this message in context:
http://www.nabble.com/DataSource-configuration-for-production-tp17695975p18012556.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
it must appear to the caller that the
>>> connection is actually closed, so methods like isClosed should
>>> return true.
>>>
>>> Instead of changing the isClosed method, I'll change the reallyClose
>>> method so it only checks the real connection before closing.
>>>
>>> -dain
>>
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/DataSource-configuration-for-production-tp17695975p18012556.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
is closed, it must appear to the caller that the
>> connection is actually closed, so methods like isClosed should
>> return true.
>>
>> Instead of changing the isClosed method, I'll change the reallyClose
>> method so it only checks the real connection bef
I think I have finally fixed this issue. Can you retest and let me
know if it is working for you?
Thanks,
-dain
On Jun 16, 2008, at 10:56 AM, Dain Sundstrom wrote:
On Jun 13, 2008, at 8:43 AM, jfjames wrote:
My intention was to find an alternative to DBCP ready to be used in
production w
On Jun 13, 2008, at 8:43 AM, jfjames wrote:
My intention was to find an alternative to DBCP ready to be used in
production with OpenEJB. Since it doesn't exist, I have to change my
mind.
If you agree to commit our patch quickly, I'm OK to use DBCP in
production.
Quick status update. I sta
custom build that we can use in
>>>> 3.0.1.
>>>>
>>>> -David
>>>>
>>>>
>>>>> jfjames wrote:
>>>>>>
>>>>>> We've spent some time today investigating what actually happens in
>>>
ximum allowed by the server).
We haven't identified the exact cause of this issue : for some
unknown
reason the DelegatingConnection.close() method consider the JDBC
connection as already closed which is wrong.
Next step tomorrow ...
--
View this message in context:
http://www.nabble.com/Da
onnection.close() method consider the JDBC
connection as already closed which is wrong.
Next step tomorrow ...
--
View this message in context:
http://www.nabble.com/DataSource-configuration-for-production-tp17695975p17775606.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
ng.
Next step tomorrow ...
--
View this message in context:
http://www.nabble.com/DataSource-configuration-for-production-tp17695975p17775606.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
--
View this message in context:
http://www.nabble.com/DataSource-configur
the
>>>> pool by
>>>> the Evictor are not physically closed :
>>>> 1/ from the DataSource standpoint : the maximum size of the pool is
>>>> never
>>>> exceeded (numActive is always inferior to maxActive),
>>>> 2/ bu
ource standpoint : the maximum size of the pool is
>>> never
>>> exceeded (numActive is always inferior to maxActive),
>>> 2/ but from the dataserver standpoint : the number of connections is
>>> always increasing (up to the maximum allowed by the server).
>
he exact cause of this issue : for some
unknown
reason the DelegatingConnection.close() method consider the JDBC
connection as already closed which is wrong.
Next step tomorrow ...
--
View this message in context:
http://www.nabble.com/DataSource-configuration-for-production-tp17695975p17775606.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
legatingConnection.close() method consider the JDBC
> connection as already closed which is wrong.
>
> Next step tomorrow ...
>
--
View this message in context:
http://www.nabble.com/DataSource-configuration-for-production-tp17695975p17775606.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
nown
reason the DelegatingConnection.close() method consider the JDBC connection
as already closed which is wrong.
Next step tomorrow ...
--
View this message in context:
http://www.nabble.com/DataSource-configuration-for-production-tp17695975p17760106.html
Sent from the OpenEJB User mailing
On Jun 10, 2008, at 12:49 AM, jfjames wrote:
Sorry David, but the MAVEN source jar is empty ...
Looks like the maven-shade-plugin needs some bug fixing :)
Oh well. The two svn commands I post should give all the required
source.
-David
Sorry David, but the MAVEN source jar is empty ...
--
View this message in context:
http://www.nabble.com/DataSource-configuration-for-production-tp17695975p17749654.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
On Jun 9, 2008, at 3:22 AM, jfjames wrote:
We're going to spend some times this afternoon investigating what
really
happens in DBCP and COMMON-POOLS. BTW do you know how we can access
the JAVA
source of DBCP and COMMON-POOLS embedded in OPENJB 3.0 ?
I'll see if I can give your scenario a t
rce of DBCP and COMMON-POOLS embedded in OPENJB 3.0 ?
Thanks in advance.
--
View this message in context:
http://www.nabble.com/DataSource-configuration-for-production-tp17695975p17730022.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
On Jun 6, 2008, at 9:10 AM, jfjames wrote:
I'm doing some tests before putting OpenEJB in production and I'm
facing a
problem with the DataSource configuration.
My environment is :
1/ Application deployed on Tomcat 6.0.16 + Open EJB 3.0,
2/ Database : MySQL 4.0.1 + Mysql Connector 5.0.4
3/
need to resolve
it before going to production.
Any help appreciated.
--
View this message in context:
http://www.nabble.com/DataSource-configuration-for-production-tp17695975p17695975.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
20 matches
Mail list logo
