On Jul 25, 2007, at 6:30 AM, Ueberbach, Michael wrote:
Many thanks to all who answered.
To the (minor) issue concerning the LIKE operator with ESCAPE clause:
The MySQL version I use supports this kind of select. Using the
appropriate property inside the persistance.xml (as Peter said) is
an interesting hint (thanks). But this is a more static way of
describing the case, I tried to do this dynamically.
To answer the other questions:
The MySQL database is created outside geronimo (by script). The
database remains and will not be created again.
The Geronimo database connection pool was deployed using the
console (so I have no plan). Only the neccessary entries were made
(name, driver class, connection details), all default values were
accepted (except one: minimum size of pool was set to 1)
The persistance.xml is the following:
<persistence>
<persistence-unit name="StammdatenVerwaltung">
<description>Zugriff auf Stammdaten</description>
<provider>org.apache.openjpa.persistence.PersistenceProviderImpl</
provider>
<jta-data-source>MySQLPool</jta-data-source>
<non-jta-data-source>MySQLPool</non-jta-data-source>
</persistence-unit>
</persistence>
I compared three szenarios, always starting with both database and
geronimo down:
1.
Starting DB
Starting Geronimo
Client call --> Exception (Access denied for user
'geronimo'@'localhost' to database 'GERONIMO_DB')
Stopping DB
Starting DB
Client call --> ok
2.
Starting Geronimo
Starting DB
Client call --> Exception (Access denied for user
'geronimo'@'localhost' to database 'GERONIMO_DB')
Stopping DB
Starting DB
Client call --> ok
3.
Starting Geronimo
Client call --> Exception (Unable to obtain physical connection to
jdbc:mysql://localhost:3306/geronimo_db)
Starting DB
Client call --> ok
(Client call means call of session bean method fetching data from
standalone java client)
At the moment (for testing) I can live with this handling, but for
productive purposes this would be a problem.
The only thing unusual in this is that you have set the pool min size
to 1 rather than 0. IIRC this means that the first connection in the
pool will have been created without a client request for a
connection. This is the connection that is causing the problems.
Could you see what happens if you set the min size to 0? If that
fixes the problem please file a jira issue with the details above, it
means that the "min size" connections aren't getting created correctly.
many thanks!
david jencks
Thanks
Michael
-----Ursprüngliche Nachricht-----
Von: David Jencks [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 23. Juli 2007 23:26
An: [email protected]
Betreff: Re: Still remaining problems using openJPA
