Using the JDBC API for Database Access
This chapter describes how to use the Java Database Connectivity (JDBC) API for database access with Payara Server.
This chapter also provides high level JDBC implementation instructions for servlets and EJB components deployed in Payara Server.
Payara Server does not support connection pooling or transactions for an application’s database access if it does not use standard Jakarta EE DataSource objects.
|
Statements
Using an Initialization Statement
You can specify a SQL statement that executes each time a physical connection to the database is created (not reused) from a JDBC connection pool. This is useful for setting request or session specific properties and is suited for homogeneous requests in a single application.
Set the Init SQL attribute of the JDBC connection pool to the SQL string to be executed in one of the following ways:
-
Enter an Init SQL value in the Edit Connection Pool Advanced Attributes page in the Administration Console.
-
Specify the
--initsql
option in theasadmin create-jdbc-connection-pool
command. -
Specify the
init-sql
option in theasadmin set
command. For example:asadmin set domain1.resources.jdbc-connection-pool.DerbyPool.init-sql="sql-string"
Setting a Statement Timeout
An abnormally long-running SQL query executed by an application may leave it in a hanging state unless a timeout is explicitly set on the statement. Setting a statement timeout guarantees that all queries automatically time out if not completed within the specified period.
When statements are created, the queryTimeout
is set according to the statement timeout setting. This works only when the underlying JDBC driver supports queryTimeout
for Statement
, PreparedStatement
, CallableStatement
, and ResultSet
.
You can specify a statement timeout in the following ways:
-
Enter a Statement Timeout value in the Edit Connection Pool Advance Attributes page in the Administration Console.
-
Specify the
--statementtimeout
option in theasadmin create-jdbc-connection-pool
command.
Statement Leak Detection and Leaked Statement Reclamation
If SQL statements are not closed by an application after use, it is possible for the application to run out of cursors. Enabling statement leak detection causes statements to be considered as leaked if they are not closed within a specified period. Additionally, leaked statements can be reclaimed automatically.
To enable statement leak detection, set Statement Leak Timeout In Seconds for the JDBC connection pool to a positive, nonzero value in one of the following ways:
-
Specify the
--statementleaktimeout
option in thecreate-jdbc-connection-pool
subcommand. For more information, seecreate-jdbc-connection-pool
. -
Specify the
statement-leak-timeout-in-seconds
option in theset
subcommand. For example:asadmin set resources.jdbc-connection-pool.pool-name.statement-leak-timeout-in-seconds=300
When selecting a value for Statement Leak Timeout In Seconds, make sure that:
-
It is less than the Connection Leak Timeout; otherwise, the connection could be closed before the statement leak is recognized.
-
It is greater than the Statement Timeout; otherwise, a long-running query could be mistaken as a statement leak.
After enabling statement leak detection, enable leaked statement reclamation by setting the Reclaim Leaked Statements setting for the JDBC connection pool to a true
value in one of the following ways:
-
Specify the
--statementleakreclaim=true
option in thecreate-jdbc-connection-pool
subcommand. For more information, seecreate-jdbc-connection-pool
. -
Specify the
statement-leak-reclaim
option in theset
subcommand. For example:asadmin set resources.jdbc-connection-pool.pool-name.statement-leak-reclaim=true
Statement Caching
Statement caching stores statements, prepared statements, and callable statements that are executed repeatedly by applications in a cache, thereby improving performance. Instead of the statement being prepared each time, the cache is searched for an existing match. The overhead of parsing and creating new statements each time is eliminated.
Statement caching is usually a feature of the JDBC driver. Payara Server provides caching for drivers that do not support caching, so consider using this feature after studying whether your JDBC driver supports statement caching. |
To enable this feature, set the Statement Cache Size for the JDBC connection pool in one of the following ways:
-
Enter a Statement Cache Size value in the Edit Connection Pool Advanced Attributes page in the Administration Console.
-
Specify the
--statementcachesize
option in theasadmin create-jdbc-connection-pool
command. -
Specify the
statement-cache-size
option in theasadmin set
command. For example:asadmin set domain1.resources.jdbc-connection-pool.DerbyPool.statement-cache-size=10
By default, this attribute is set to zero and the statement caching is turned off. |
To enable statement caching, you can set any positive nonzero value. The built-in cache eviction strategy is LRU-based (Least Recently Used).
When a connection pool is flushed, the connections in the statement cache are recreated.
SQL Trace Listeners
Payara Server provides support for custom SQL Trace Listeners. A SQL Trace Listener is registered against a data source and is called after each method call made on the JDBC connection pool.
SQL Trace Listeners allows developers to track all calls to the database and can be used to develop custom auditing, error handling or monitoring components. SQL Trace Listeners can be enabled globally on a data source if the class that implements it is on the server’s classpath, or can be enabled on application specific data sources by including them in the application’s WAR or EAR.
SQL Trace listener Interface
The SQL Trace Listener interface is shown below:
public interface SQLTraceListener {
/**
* Notify listeners with SQL trace information.
* @param record SQLTraceRecord that has information related
* to the SQL operation
*/
public void sqlTrace(SQLTraceRecord record);
}
To write a custom trace listener you need to implement the interface and override the sqlTrace
method. The SQLTraceRecord
object contains information about the executed call to the JDBC connection pool. The following is the list of properties that can be queried using their respective getter methods:
/**
* Thread ID from which SQL statement originated.
*/
private long threadID;
/**
* Thread Name from which SQL statement originated.
*/
private String threadName;
/**
* Pool Name in which the SQL statement is executed.
*/
private String poolName;
/**
* Type of SQL query. Could be PreparedStatement, CallableStatement or
* other object types.
*/
private String className;
/**
* Method that executed the query.
*/
private String methodName;
/**
* Time of execution of query.
*/
private long timeStamp;
/**
* Parameters of the method that executed the SQL query. Includes information
* like SQL query, arguments and so on.
*/
private Object[] params;
SQL Trace Listener Example
The following code fragment illustrates an example SQL trace listener that just logs the executed call to the server’s log file:
public class SQLTraceLogger implements SQLTraceListener {
private static Logger _logger = initLogger();
private static Logger initLogger() {
_logger = LogDomains.getLogger(SQLTraceLogger.class, LogDomains.SQL_TRACE_LOGGER);
return _logger;
}
public SQLTraceLogger() {
}
public void sqlTrace(SQLTraceRecord record) {
_logger.log(Level.FINE, record.toString());
}
}
SQL Trace Listener Logger
Payara Server provides an SQL tracing logger to log the SQL operations in the form of SQLTraceRecord
objects in the server.log
file. The module name under which the SQL operation is logged is javax.enterprise.resource.sqltrace
.
SQL traces are logged as FINE
messages along with the module name to enable easy filtering of the SQL logs. A sample SQL trace record looks like this:
[#|2009-11-27T15:46:52.202+0530|FINE|Payara Server 6.19.0|jakarta.enterprise.resource.sqltrace.com.sun.gjc.util
|_ThreadID=29;_ThreadName=Thread-1;ClassName=com.sun.gjc.util.SQLTraceLogger;MethodName=sqlTrace;
|ThreadID=77 | ThreadName=p: thread-pool-1; w: 6 | TimeStamp=1259317012202
| ClassName=com.sun.gjc.spi.jdbc40.PreparedStatementWrapper40 | MethodName=executeUpdate
| arg[0]=insert into table1(colName) values(100) | arg[1]=columnNames | |#]
This trace shows that an executeUpdate(String sql, String columnNames)
operation is being done.
When SQL statement tracing is enabled and JDBC connection pool monitoring is enabled, Payara Server maintains a tracing cache of recent queries and their frequency of use. The following JDBC connection pool properties can be configured to control this cache and the monitoring statistics available from it:
time-to-keep-queries-in-minutes
-
Specifies how long in minutes to keep a query in the tracing cache, tracking its frequency of use. The default value is
5
minutes. number-of-top-queries-to-report
-
Specifies how many of the most used queries, in frequency order, are listed the monitoring statistic. The default value is
10
queries.
Set these parameters in one of the following ways:
-
Add them as custom properties in the Edit JDBC Connection Pool Properties page in the Administration Console.
-
Specify them using the
--property
option in thecreate-jdbc-connection-pool
subcommand. For more information, seecreate-jdbc-connection-pool
. -
Set them using the
set
subcommand. For example:asadmin set resources.jdbc-connection-pool.pool-name.property.time-to-keep-queries-in-minutes=10
Configuring SQL Trace Listeners
To configure the listeners used by a connection pool set the SQL Trace Listeners attribute to a comma-separated list of trace listener implementation classes in one of the following ways:
-
Enter an SQL Trace Listeners value in the Edit Connection Pool Advanced Attributes page in the Administration Console.
-
Specify the
--sqltracelisteners
option in theasadmin create-jdbc-connection-pool
command. -
Specify the
sql-trace-listeners
option in theasadmin set
command. For example:asadmin set domain1.resources.jdbc-connection-pool.DerbyPool.sql-trace-listeners=listeners
To make custom implementations of this interface available to Payara Server, place the implementation classes in as-install/lib
.
More information on how to configure SQL Trace listeners can be read in the JDBC Connection Pool configuration of Payara Server’s administration section.
Connections
Transparent Pool Reconfiguration
When the properties or attributes of a JDBC connection pool are changed, the connection pool is destroyed and re-created. Normally, applications using the connection pool must be redeployed as a consequence. This restriction can be avoided by enabling transparent JDBC connection pool reconfiguration. When this feature is enabled, applications do not need to be redeployed. Instead, requests for a new connections are blocked until the reconfiguration operation completes.
Connection requests from any "in-flight" transactions are served using the old pool configuration to complete the transaction. Then, connections are created using the pool’s new configuration, and any blocked connection requests are served with connections from the re-created pool.
To enable transparent JDBC connection pool reconfiguration, set the dynamic-reconfiguration-wait-timeout-in-seconds
property of the JDBC connection pool to a positive, nonzero value in one of the following ways:
-
Add it as a property in the Edit JDBC Connection Pool Properties page in the Administration Console.
-
Specify it using the
--property
option in thecreate-jdbc-connection-pool
subcommand. For more information, seecreate-jdbc-connection-pool
. -
Set it using the
set
subcommand. For example:asadmin set resources.jdbc-connection-pool.pool-name.property.dynamic-reconfiguration-wait-timeout-in-seconds=15
This property specifies the time in seconds to wait for in-use connections to close and in-flight transactions to complete. Any connections in use or transaction in flight past this time must be retried.
Disabling Pooling
To disable connection pooling, set the Pooling attribute to false. The default is true
. You can enable or disable connection pooling in one of the following ways:
-
Enter a Pooling value in the Edit Connection Pool Advanced Attributes page in the Administration Console.
-
Specify the
--pooling
option in theasadmin create-jdbc-connection-pool
command. -
Specify the
pooling
option in theasadmin set
command. For example:asadmin set domain1.resources.jdbc-connection-pool.H2Pool.pooling=false
The pooling option and the system property com.sun.enterprise.connectors.SwitchoffACCConnectionPooling , which turns off connection pooling in the Application Client Container, do not affect each other.
|
An exception is thrown if associate-with-thread
is set to true
and pooling is disabled. An exception is thrown if you attempt to flush a connection pool when pooling is disabled. A warning is logged if the following attributes are used, because they are useful only in a pooled environment:
-
connection-validation
-
validate-atmost-once-period
-
match-connections
-
max-connection-usage
-
idle-timeout
Associating Connections with Threads
To associate connections with a thread, set the Associate With Thread attribute to true
. The default is false
. A true
setting allows connections to be saved as ThreadLocal
in the calling thread.
Connections get reclaimed only when the calling thread dies or when the calling thread is not in use and the pool has run out of connections. |
If the setting is false
, the thread must obtain a connection from the pool each time the thread requires a connection.
The Associate With Thread attribute associates connections with a thread such that when the same thread is in need of connections, it can reuse the connections already associated with that thread. In this case, the overhead of getting connections from the pool is avoided.
However, when this value is set to true
, you should verify that the value of the Max Pool Size attribute is comparable to the Max Thread Pool Size attribute of the thread pool. If the Max Thread Pool Size value is much higher than the Max Pool Size value, a lot of time is spent associating connections with a new thread after dissociating them from an older one. Use this attribute in cases where the thread pool should reuse connections to avoid this overhead.
You can set the Associate With Thread attribute in the following ways:
-
Enter an Associate With Thread value in the Edit Connection Pool Advanced Attributes page in the Administration Console.
-
Specify the
--associatewiththread
option in theasadmin create-jdbc-connection-pool
command. -
Specify the
associate-with-thread
option in theasadmin set
command. For example:asadmin set domain1.resources.jdbc-connection-pool.DerbyPool.associate-with-thread=true
Custom Connection Validation
You can specify a custom implementation for Connection Validation that is faster or optimized for a specific database.
Set the Validation Method attribute to the value custom-validation
.
Payara Server provides a public interface, org.glassfish.api.jdbc.ConnectionValidation
, which you can implement to plug in your custom implementation.
The Validation Classname attribute, specifies the fully qualified name of the class that implements the ConnectionValidation
interface.
The Validation Classname attribute is required if Connection Validation is enabled and Validation Method is set to Custom Validation.
To enable this feature, set Connection Validation, Validation Method, and Validation Classname for the JDBC connection pool in one of the following ways:
-
Enter Connection Validation, Validation Method, and Validation Classname values in the Edit Connection Pool Advanced Attributes page in the Administration Console.
You can select from among validation class names for common databases in the Validation Classname field.
-
Specify the
--isconnectionvalidatereq
,--validationmethod
, and--validationclassname
options in theasadmin create-jdbc-connection-pool
command. -
Specify the
is-connection-validation-required
,connection-validation-method
, andvalidation-classname
options in theasadmin set
command. For example:asadmin set domain1.resources.jdbc-connection-pool.MyPool.is-connection-validation-required=true asadmin set domain1.resources.jdbc-connection-pool.MyPool.connection-validation-method=custom-validation asadmin set domain1.resources.jdbc-connection-pool.MyPool.validation-classname=impl-class
By default, optimized validation mechanisms are provided for DB2, H2, Apache Derby, MSSQL, MySQL, Oracle, PostgreSQL and Sybase databases.
Additionally, for JDBC 4.0 compliant database drivers, a validation mechanism is provided that uses the Connection.isValid(0)
implementation.
Sharing Connections
When multiple connections acquired by an application use the same JDBC resource, the connection pool provides connection sharing within the same transaction scope.
For example, suppose Bean A starts a transaction and obtains a connection, then calls a method in Bean B. If Bean B acquires a connection to the same JDBC resource with the same sign-on information, and if Bean A completes the transaction, the connection can be shared.
Connections obtained through a resource are shared only if the resource reference declared by the Jakarta EE component allows it to be shareable. This is specified in a component’s deployment descriptor by setting the res-sharing-scope element to Shareable for the particular resource reference.To turn off connection sharing, set res-sharing-scope to Unshareable .
|
For general information about connections and JDBC URLs, see "Administering Database Connectivity" in the Payara Server General Administration section.
Marking Bad Connections
The default DataSource
implementation in Payara Server provides a markConnectionAsBad
method. A marked bad connection is removed from its connection pool when it is closed and is not returned to the pool. The method signature is as follows:
public class Datasource{
public void markConnectionAsBad(java.sql.Connection connection){
}
}
For example:
public class ApplicationComponent{
public void operation(){
var ds = (com.sun.appserv.jdbc.DataSource)context.lookup("jdbc/myDataSource");
try(var con = ds.getConnection(); //Connection will be destroyed during close.
var stmt = con.createStatement()){
stmt.executeUpdate("Update");
}
catch (BadConnectionException e){
ds.markConnectionAsBad(con);
}
}
}
Handling Invalid Connections
If a ConnectionErrorOccured
event occurs, Payara Server considers the connection invalid and removes the connection from the connection pool. Typically, a JDBC driver generates a ConnectionErrorOccured
event when it finds a ManagedConnection
object unusable. Reasons can be database failure, network failure with the database, fatal problems with the connection pool, and so on.
If the fail-all-connections
setting in the connection pool configuration is set to true
, and a single connection fails, all connections are closed and recreated. If this setting is false
, individual connections are recreated only when they are used. The default is false
.
The is-connection-validation-required
setting specifies whether connections have to be validated before being given to the application. If a resource’s validation fails, it is destroyed, and a new resource is created and returned. The default is false
.
The prefer-validate-over-recreate
property specifies that validating idle connections is preferable to closing them. This property has no effect on non-idle connections. If set to true
, idle connections are validated during pool resizing, and only those found to be invalid are destroyed and recreated.
If false
, all idle connections are destroyed and recreated during pool resizing. The default is false
.
You can set the fail-all-connections
, is-connection-validation-required
, and prefer-validate-over-recreate
configuration settings during creation of a JDBC connection pool. Or, you can use the asadmin set
command to dynamically reconfigure these settings. For example:
asadmin set server.resources.jdbc-connection-pool.MyPool.fail-all-connections="true"
asadmin set server.resources.jdbc-connection-pool.MyPool.is-connection-validation-required="true"
asadmin set server.resources.jdbc-connection-pool.MyPool.property.prefer-validate-over-recreate="true"
The interface ValidatingManagedConnectionFactory exposes the method getInvalidConnections to allow retrieval of the invalid connections.Payara Server checks if the JDBC driver implements this interface, and if it does, invalid connections are automatically removed when the connection pool is resized. |
Connection Wrapping
Wrapping Connections
If the Wrap JDBC Objects option is true
(the default), wrapped JDBC objects are returned for Statement
, PreparedStatement
, CallableStatement
, ResultSet
, and DatabaseMetaData
.
This option ensures that Statement.getConnection()
is the same as DataSource.getConnection()
. Therefore, this option should be true
when both Statement.getConnection()
and DataSource.getConnection()
are done.
You can specify the Wrap JDBC Objects option in the following ways:
-
Check or uncheck the Wrap JDBC Objects box on the Edit Connection Pool Advanced Attributes page in the Administration Console.
-
Specify the
--wrapjdbcobjects
option in theasadmin create-jdbc-connection-pool
command.
Obtaining a Physical Connection From a Wrapped Connection
The default DataSource
implementation in Payara Server provides a getConnection
method that retrieves the JDBC driver’s SQLConnection
from Payara Server’s Connection
wrapper.
The method signature is as follows:
import java.sql.Connection;
public class Connection{
public Connection getConnection(Connection con) throws java.sql.SQLException;
}
For example:
import java.sql.Connection;
public class MyComponent{
public void operation(){
var ctx = new InitialContext();
var ds = (com.sun.appserv.jdbc.DataSource)ctx.lookup("jdbc/MyBase");
try(var con = ds.getConnection(); //return wrapped connection to pool on close.
var drivercon = ds.getConnection(con)){
// Do db operations.
}
}
}
Using the Connection.unwrap()
Method
Using the Connection.unwrap()
method on a vendor-provided interface returns an object or a wrapper object implementing the vendor-provided interface, which the application can make use of to do vendor-specific database operations. Use the Connection.isWrapperFor()
method on a vendor-provided interface to check whether the connection can provide an implementation of the vendor-provided interface.
Check your corresponding JDBC driver vendor’s documentation for information on these interfaces.
Allowing Non-Component Callers
You can allow non-Jakarta-EE components, such as lifecycle modules and third party persistence managers, to use a managed JDBC connection pool.
The returned connection is automatically enlisted with the transaction context obtained from the transaction manager. Standard Jakarta EE components can also use such pools.
Connections obtained by non-component callers are not automatically closed at the end of a transaction by the container. They must be explicitly closed by the caller. |
You can enable non-component callers in the following ways:
-
Check the Allow Non Component Callers box on the Edit Connection Pool Advanced Attributes page in the Administration Console. The default is
false
. -
Specify the
--allownoncomponentcallers
option in theasadmin create-jdbc-connection-pool
command. -
Specify the
allow-non-component-callers
option in theasadmin set
command. For example:asadmin set domain1.resources.jdbc-connection-pool.DerbyPool.allow-non-component-callers=true
-
Create a JDBC resource with a
__pm
suffix.
Accessing a DataSource
using the Synchronization.beforeCompletion()
method requires setting Allow Non Component Callers to true
. For more information about the Transaction Synchronization Registry, see The Transaction Manager, the Transaction Synchronization Registry, and UserTransaction
.
Using Application-Scoped Resources
You can define an application-scoped database or other resources for an enterprise application, web module, EJB module, connector module, or application client module by supplying a payara-resources.xml
deployment descriptor file.
For more details, see "Application-Scoped Resources" in the Payara Server Application Deployment section.
JDBC Development Guidelines
In Jakarta EE applications and above, a JDBC data source can be deployed by adding the @DataSourceDefinition
annotation to a managed component (like and @Stateless
EJB bean for example). The Log JDBC Calls setting can be configured using this annotation as well:
@DataSourceDefinition(
name = "java:app/MyApp/MyDS",
className = "org.h2.jdbcx.JdbcDataSource",
url = "jdbc:h2:mem:test",
properties = {"fish.payara.log-jdbc-calls=true"})
public class JDBCComponent{
}
The Data source definition can also be added to a deployment descriptor of an application, for example in the web.xml
standard deployment descriptor:
<data-source>
<name>java:global/ExampleDataSource</name>
<class-name>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</class-name>
<server-name>localhost</server-name>
<port-number>3306</port-number>
<database-name>mysql</database-name>
<user>test</user>
<password>test</password>
<!-- Example of how to use a Payara Server specific custom connection pool setting -->
<property>
<name>fish.payara.log-jdbc-calls</name>
<value>true</value>
</property>
</data-source>
Or in the definition of a jdbc-connection-pool
in a payara-resources.xml
file:
<jdbc-connection-pool name="examplePool"
res-type="javax.sql.DataSource"
datasource-classname="org.h2.jdbcx.JdbcDataSource" log-jdbc-calls="true">
<property name="user" value="test"/>
<property name="password" value="test"/>
<property name="url" value="java:global/ExampleDataSource"/>
</jdbc-connection-pool>
This can also be done in the creation of a JDBC Connection Pool with the --logjdbccalls
option.
asadmin create jdbc-connection-pool --datasourceclassname org.h2.jdbcx.JdbcDataSource --restype javax.sql.XADataSource --logjdbccalls=true examplePool
Likewise, you can configure the Slow Query Log Threshold time by setting the property fish.payara.slow-query-threshold-in-seconds
, SQL Trace Listener classes by setting the property fish.payara.sql-trace-listeners
in the @DataSourceDefinition
annotation.
The below example shows the Slow Query Log Threshold and SQL Trace Listener set in the web.xml file.
<data-source>
<name>java:global/ExampleDataSource</name>
<class-name>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</class-name>
<server-name>localhost</server-name>
<port-number>3306</port-number>
<database-name>mysql</database-name>
<user>test</user>
<password>test</password>
<!-- Example of how to use a Payara specific custom connection pool setting -->
<property>
<name>fish.payara.log-jdbc-calls</name>
<value>true</value>
</property>
<property>
<name>fish.payara.slow-query-threshold-in-seconds</name>
<value>5</value>
</property>
<property>
<name>fish.payara.sql-trace-listeners</name>
<value>fish.payara.examples.payaramicro.datasource.example.CustomSQLTracer</value>
</property>
</data-source>
Slow Query Trace Example
Below is an example WARNING
trace for a slow query recollected from the server’s log:
[#|2016-02-01T22:39:29.289+0000|WARNING|Payara 4.1|jakarta.enterprise.resource.sqltrace.com.sun.gjc.util|_ThreadID=61;_ThreadName=http-listener-1(2);_TimeMillis=1454366369289;_LevelValue=900;|
SQL Query Exceeded Threshold Time: 5000(ms): Time Taken: 10000(ms)
Query was SELECT ID, AGE, BIO, BIRTHDATE, BIRTHDAY, DATEFORMAT, DATEOFBIRTH, DATEOFHIRE, EMAIL, HIREDATE, HIREDAY, MEMBERAGE, NAME, TODAYSDATE FROM MEMBERENTITY WHERE (NAME = ?);
java.lang.Exception: Stack Trace shows code path to SQL
at fish.payara.jdbc.SlowSQLLogger.sqlTrace(SlowSQLLogger.java:123)
at com.sun.gjc.util.SQLTraceDelegator.sqlTrace(SQLTraceDelegator.java:122)
at com.sun.gjc.spi.jdbc40.ProfiledConnectionWrapper40$1.invoke(ProfiledConnectionWrapper40.java:448)
at com.sun.proxy.$Proxy265.executeQuery(Unknown Source)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.executeSelect(DatabaseAccessor.java:1009)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.basicExecuteCall(DatabaseAccessor.java:644)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.executeCall(DatabaseAccessor.java:560)
at org.eclipse.persistence.internal.sessions.AbstractSession.basicExecuteCall(AbstractSession.java:2055)
at org.eclipse.persistence.sessions.server.ServerSession.executeCall(ServerSession.java:570)
at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:242)
at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:228)
at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeSelectCall(DatasourceCallQueryMechanism.java:299)
at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.selectAllRows(DatasourceCallQueryMechanism.java:694)
at org.eclipse.persistence.internal.queries.ExpressionQueryMechanism.selectAllRowsFromTable(ExpressionQueryMechanism.java:2740)
at org.eclipse.persistence.internal.queries.ExpressionQueryMechanism.selectAllRows(ExpressionQueryMechanism.java:2693)
at org.eclipse.persistence.queries.ReadAllQuery.executeObjectLevelReadQuery(ReadAllQuery.java:559)
at org.eclipse.persistence.queries.ObjectLevelReadQuery.executeDatabaseQuery(ObjectLevelReadQuery.java:1175)
at org.eclipse.persistence.queries.DatabaseQuery.execute(DatabaseQuery.java:904)
at org.eclipse.persistence.queries.ObjectLevelReadQuery.execute(ObjectLevelReadQuery.java:1134)
at org.eclipse.persistence.queries.ReadAllQuery.execute(ReadAllQuery.java:460)
at org.eclipse.persistence.queries.ObjectLevelReadQuery.executeInUnitOfWork(ObjectLevelReadQuery.java:1222)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.internalExecuteQuery(UnitOfWorkImpl.java:2896)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1857)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1839)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1804)
at org.eclipse.persistence.internal.jpa.QueryImpl.executeReadQuery(QueryImpl.java:258)
at org.eclipse.persistence.internal.jpa.QueryImpl.getResultList(QueryImpl.java:473)
at fish.payara.team.info.controllers.MemberSessionBean.getTeamMemberByName(MemberSessionBean.java:35)