tomee-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oliver Guenther (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (TOMEE-1337) Usage of com.mysql.jdbc.jdbc2.optional.MysqlXADataSource in Tomee 1.7.0 not possible
Date Thu, 04 Sep 2014 12:25:51 GMT

    [ https://issues.apache.org/jira/browse/TOMEE-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14121296#comment-14121296
] 

Oliver Guenther commented on TOMEE-1337:
----------------------------------------

This is probably a tough nut to crack.

First, I'm also sure now, that all transaction are commited correctly. But I assume the pooling
of the jdbc connection is wrong as for each transaction a new connection is used and none
are reuse. The new problem is the sometimes different behavior of mysql. Sometimes it's fast
enought to close the unused connections fast enought, so the mysql user does not reach his
limit. But sometimes not.

I supplied an example to start with.
Check out https://github.com/og0815/sandbox
under tomee-mysql-xa/entity 
See the BookPu class for a mysql datasource. Change to your environment.
calling mvn clean install will run a test against that source.

A possible Mysql Instance is here as VirtualBox VM: http://www.gg-net.de/test/tomee.test.tar.bz2
Accounts: root / test
Mysql: root / test and testuser / testuser

Now I have seen two possible outcomes to the test. Either the test Fails with a Exception,
that there are no more connections to the mysql instance allowed. As long as the server is
active, you can see that multiple mysql connections are open. 
On the other hand the test might run trough (happens if you run it directly on the vm), but
while it runs multiple connections (50 - 90) are opened and closed on the mysql side.

So to sum up again, I would assume that the tomcat-dbcp oder apache-dbcp would use some strategy
to reuse a connection. Especially if all db calles are done from one jvm thread.
Our actually workaround is to allow unlimited connections to the mysql db.

If you change the project to openejb 4.6.0 and the config likewise, you can see that there
are only one or two connections open over the time.


> Usage of com.mysql.jdbc.jdbc2.optional.MysqlXADataSource in Tomee 1.7.0 not possible
> ------------------------------------------------------------------------------------
>
>                 Key: TOMEE-1337
>                 URL: https://issues.apache.org/jira/browse/TOMEE-1337
>             Project: TomEE
>          Issue Type: Bug
>    Affects Versions: 1.7.0
>         Environment: Debian GNU/Linux 7.x 64bit
> Oracle Java 8u20 64 bit 
> Mysql 5.5.38
>            Reporter: Oliver Guenther
>            Priority: Critical
>
> If you want to use the mysql xa datasource, the configuration parameters are ignored.
> To reproduce:
> Install mysql 5.5
> Install tomee.
> Create a database in mysql.
> Modify the tomee.xml like this.
> {code:xml}
> <Resource id="repairDataSource" type="javax.sql.DataSource">
>   JdbcDriver com.mysql.jdbc.jdbc2.optional.MysqlXADataSource
>   JdbcUrl jdbc:mysql://localhost/database
>   UserName YYYY
>   Password XXXX
>   JtaManaged true
> </Resource>
> {code}
> Start tomee.
> You will see some warnings in the log like this.
> [main] INFO  unknown.jul.logger - Creating Resource(id=repairDataSource)
> [main] WARN  unknown.jul.logger - Property "JdbcUrl" not supported by "repairDataSource"
> WARN  unknown.jul.logger - Property "UserName" not supported by "repairDataSource"
> WARN  unknown.jul.logger - Property "Password" not supported by "repairDataSource"
> WARN  unknown.jul.logger - Property "PasswordCipher" not supported by "repairDataSource"
> WARN  unknown.jul.logger - Property "ConnectionProperties" not supported by "repairDataSource"
> WARN  unknown.jul.logger - Property "DefaultAutoCommit" not supported by "repairDataSource"
> WARN  unknown.jul.logger - Property "DefaultReadOnly" not supported by "repairDataSource"
> WARN  unknown.jul.logger - Property "InitialSize" not supported by "repairDataSource"
> WARN  unknown.jul.logger - Property "MaxActive" not supported by "repairDataSource"
> WARN  unknown.jul.logger - Property "MaxIdle" not supported by "repairDataSource"
> WARN  unknown.jul.logger - Property "MinIdle" not supported by "repairDataSource"
> WARN  unknown.jul.logger - Property "ValidationQuery" not supported by "repairDataSource"
> WARN  unknown.jul.logger - Property "TestOnBorrow" not supported by "repairDataSource"
> WARN  unknown.jul.logger - Property "TestOnReturn" not supported by "repairDataSource"
> WARN  unknown.jul.logger - Property "TestWhileIdle" not supported by "repairDataSource"
> WARN  unknown.jul.logger - Property "NumTestsPerEvictionRun" not supported by "repairDataSource"
> WARN  unknown.jul.logger - Property "PoolPreparedStatements" not supported by "repairDataSource"
> WARN  unknown.jul.logger - Property "MaxOpenPreparedStatements" not supported by "repairDataSource"
> WARN  unknown.jul.logger - Property "AccessToUnderlyingConnectionAllowed" not supported
by "repairDataSource" 
> The DataSoruce itself can be discovered via JNDI in the application but is not configured
probably.
> A usage results in a SQL Exception, saying user 'sa' has no access rights in the database.

> It seams that the configuration parameters are ignored and some default values from HSQLDB
are used.
> Using the "JdbcDriver com.mysql.jdbc.Driver" solves the issue, but this driver does not
support any XA abilities.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message