[GLASSFISH-3942] Provide a cluster-aware Database "Ping" feature Created: 24/Dec/07  Updated: 26/Apr/11

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 9.1peur1
Fix Version/s: None

Type: Improvement Priority: Critical
Reporter: Alexis MP Assignee: Shalini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 3,942
Status Whiteboard:

clusteradmin


 Description   

Database Ping works well with a single instance. In cluster mode, having the DAS
be able to ping the database doesn't mean all cluster instances can do it as
well (the JDBC driver may not be present or correctly loaded on each local
instance for instance).



 Comments   
Comment by km [ 13/Jan/08 ]

....

Comment by Tom Mueller [ 14/May/10 ]

Once the infrastructure work for dynamic configuration is done for 3.1, this
behavior should be implemented automatically. So this feature just needs to be
tested later during the release cycle.

The relevant subcommand is ping-connection-pool.

Comment by Tom Mueller [ 17/May/10 ]

Marking as referenced by the clustering admin one-pager.

Comment by Tom Mueller [ 25/Jan/11 ]

Clear the Fix version since this issue isn't going to be fixed for 3.1.





[GLASSFISH-12568] JDBC resource need to allow system property for pool name Created: 07/Jul/10  Updated: 13/Dec/10

Status: Open
Project: glassfish
Component/s: jdbc
Affects Version/s: 3.1
Fix Version/s: None

Type: Improvement Priority: Critical
Reporter: Anissa Lam Assignee: Shalini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 12,568

 Description   

In the JDBC resource screen, the connection pool is a drop down list.
This means user cannot use system properties ie, token to specify a pool name. eg $

{PoolName}

To support such use case, the dropdown needs to be a 'combo box', allowing user to select from
dropdown or enter the pool name. Client side validation should ensure that it starts with "${"

Currently, CLI allows that.
This will be JDBC enhancement.



 Comments   
Comment by Shalini [ 08/Jul/10 ]

This needs to be done for Connector Connection pools also.

Comment by sumasri [ 06/Oct/10 ]

Added the target milestone.

Comment by sumasri [ 22/Oct/10 ]

-> MS7

Comment by sumasri [ 29/Nov/10 ]

In V2.1 also, There is no way to add a system property as pool name through GUI.
Steps to do it in CLI is,
1)Create a node agent na.
2)Create a cluster(c1).
3)Create an instance(i1) under cluster c1 with the node agent na.
4)start the node agent(na).
5)Create a system property(Ex: poolname=DerbyPool) with the target as c1.
6)Create a jdbc resource using the target c1 and pool name as "$

{poolname}".
command : asadmin create-jdbc-resource --connectionpoolid "\${poolname}

" --target c1 jdbc1.

But, In v3.1, there is no support for start-node-agent. Through CLI, it is not supporting system property for jdbc resource creation.
Steps to reproduce the issue.
1)Create a cluster
2)Create an instance(i1) under cluster c1 with the node agent localhost.
3)Start the cluster
4)Create a system property(Ex: poolname=DerbyPool) with the target as c1.
5)./bin/asadmin create-jdbc-resource --connectionpoolid "\$

{poolname}" --target c1 j1
org.glassfish.api.admin.CommandException: remote failure: Attribute value (pool-name = ${poolname}

) is not found in list of jdbc connection pools.
Command create-jdbc-resource failed.

Transferring it to the backend team to look into the issue. Please transfer it to me for GUI support once you are done with the backend changes.





[GLASSFISH-10879] CLI commands to add/list/delete any jdbc drivers. Created: 07/Nov/09  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: jdbc
Affects Version/s: 3.1
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: felipegaucho Assignee: Shalini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux


Issuezilla Id: 10,879

 Description   

It would be very interesting if I can list the available drivers in a Glassfish
domain. This could allow my installation script to detect in advance if the
driver required by an application is available or not.

It also can be integrated in the Admin GUI, and during the deployment of an
application the GUI can show a Warning to the user about a missed JDBC driver.

In my opinion, the listing of all available resources should be available
through CLI and Admin GUI. The automatic deployment for testing or production is
a common practice and Glassfish should support the automatic build scripts as
best it can. A Hudson server, for example, is blind about the GF resources and
it may deploy application that will not work properly in the absence of a
resource, but today there is nothing Hudson can do to warn the developers about
that - specially when the server is upgraded and someone forget to install the
drivers required by the applications.



 Comments   
Comment by Bill Shannon [ 07/Nov/09 ]

Reassign.

Comment by Jagadish [ 17/Nov/09 ]

transferring to Shalini

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-2092] Deployer cannot bind a persistence-unit to an arbitrary JDBC data source without changing the EAR file Created: 18/Jan/07  Updated: 10/Oct/12

Status: Open
Project: glassfish
Component/s: jdbc
Affects Version/s: 9.1pe
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: markuskarg Assignee: Shalini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 2,092

 Description   

ISVs are used to provide .msi files to Windows users. The deployer is using the
Windows Installer Tool (as service that is part of the Windows OS) to configure
properties found in the .msi file (for example, name of the company, etc.).
This information gets processed by the Windows Installer Tool at time of
installation of the programs found inside of the .msi file.

So at least on Windows deployment is separated in stages: (a) Creation of
an .msi archive file including binaries and configurable deployment properties,
(b) Configuring properties using the configuration part of an installation
tool, (c) Copying files and writing configuration values using the installation
engine part of an installation tool. Whether this tools is called RPM,
InstallShield or Windows Installer doesn't make a difference. Nor does it
matter whether the OS is called Windows or Linux. The three stages are the same
always.

On the Java EE platform, JSR88 specifies "The Java EE Way" of these three
stages: (a) Packaging of EJB-JARs and EARs including configurable deployment
properties in the technical form of deployment descriptors and persistence.xml
files, (b) Configuring the actual set of configuration values (including
providing information missing in persistence.xml, like "which JDBC data source
to use for this persistence unit") using a configuration tool (which, in turn
uses a deployment driver in "offline mode"), (c) copying files on the server
and writing configuration values into the server's proprietary configuration
registry, using a deployment tool (which, in turn uses a deployment driver
in "online mode").

That's the way the story should go.

But actually the world seems not to be as perfect, since not all people are
using JSR88 tools to install EJB-JARs and EARs into GlassFish. Some (or: a lot
of) people still are doing steps (b) and (c) using the browser based GUI.

Those people actually are facing the problem that in step (b) they want to
configure which JDBC data source a persistence unit shall be bound to.
Unfortunately, they cannot. They have to live with the fact that each
persistence unit is bound to jdbc/__default. If they want to change it, they
must unpack the EAR and EJB-JAR to be able to change the persistence.xml file
found inside of. Then, they must repack it, to make GF load and deploy it.

This is not very convenient, since least users (1) like to unpack, edit, and
repack their modules, and (2) like to have all of their EARs running on the
same, single data base. Example: A company buys SAP, so they install SAP.ear.
It must be bound to the SAP DB obviously. Then they buy a bug tracking system,
so they install BugTrackSystem.ear. Obviously, BugTrackSystem.ear shall be
bound to the BugTrackSystem DB. Neither does the company want to unpack both
EARs and fiddle around in the persistence.xml files, nor does the company want
to have BugTrackSystem.ear and SAP.ear be bound to jdbc/__default (which, by
default, is bound to a Derby DB).

So what is missing is a way to use the Web Based Admin GUI to say "this
persistence unit had to be bound to that JDBC data source".

As that is an essential link in every GF installation, I think this is a bug
but not just some idea of a good feature.

Also, the JPA specification contains the following:

"6.2.1.5 jta-data-source, non-jta-data-source
In Java EE environments, the jta-data-source and non-jta-data-source elements
are used to specify the global JNDI name of the JTA and/or non-JTA data source
to be used by the persistence provider. If neither is specified, the deployer
must specify a JTA data source at deployment or a JTA data source must be
provided by the container. "

The GlassFish team interpreted "...at deployment time OR ... provided by the
container..." is: "We, the GlassFish team, are free to decide whether we are
providing a data source, or whether the deployer will provide one". Actually,
from the view of an ISV or end user, this is a misinterpretation. In fact, ISVs
and end users both would interprete it that way: "The deployer can tell which
JDBC data source to use. If the deployer does not tell it, the server must use
a default source.".



 Comments   
Comment by tware [ 18/Jan/07 ]

Changing component from entity-persistence to deployment

Comment by tware [ 18/Jan/07 ]

reassigning to component owner

Comment by gfbugbridge [ 19/Jan/07 ]

<BT6515334>

Comment by Hong Zhang [ 30/Jan/07 ]

-> tim

Comment by Hong Zhang [ 30/Jan/07 ]

-> accepted

Comment by Tim Quinn [ 31/Jan/07 ]

Although the description mentions deployment and deployer in several places, at
its heart this issue is requesting a change in the admin GUI.

Reassigning.

Comment by marina vatkina [ 31/Jan/07 ]

I'm not sure which component is responsible for providing the functionality, but
this option should be available via 'asadmin' as well, and the result need to
end up in the PU descriptor. What can complicate the situation, is that a PU is
not a component, and can be part of a library jar that is not exploded.

Comment by Anissa Lam [ 31/Jan/07 ]

GUI cannot provide such a feature without support from backend.
>>> So what is missing is a way to use the Web Based Admin GUI to say "this
>>> persistence unit had to be bound to that JDBC data source".

This requires more than 1 subcomponent to work together. I am assigning this to
Kedar who can decide whats the first step to solve this issue.

Comment by km [ 01/Feb/07 ]

Markus,

This seems to be (what my friend calls) a red ball.

If I am understanding you
correctly, the resource that a persistence unit (PU) needs is implicitly mapped
onto "jdbc/__default", unless <jta-data-source> is provided in the PU's xml.

If that's correct, then what Marina suggests is that we provide a capability
on the admin tools to essentially modify the persistence.xml on deployment.
Well, that is simply not consistent. We don't modify any of the deployment
descriptors during deployment using admin console or admin CLI.

AFAIU, jdbc/__default is a global resource defined out-of-the-box in GlassFish
and it points to an embedded "Java DB" database (Actually, I don't know why
it points to sun-appserv-samples!). All applications can use this datasource.

If you want jta-data-source to actually point to a "database" of your choice,
can't you

  • define a connection pool pointing to that database,
  • change the pool-name on jdbc/__default to point to that pool?

(Both these options are available on the Web Admin Console or admin CLI).

Your application remains portable and you don't have to change persistence.xml
at all.

Will that not work to satisfy the situation you describe?

Another approach would be to use application server vendor specific data-source
mapping. I don't know if that's available for persistence units, though.

Please let me know.

Comment by km [ 25/Feb/07 ]

Is this a must for GlassFish V2? I tend to make this a P4 as I don't think it
is a priority for V2 release.

Comment by km [ 21/Mar/07 ]

Markus, what should be done with this?

Comment by marina vatkina [ 21/Mar/07 ]

Kedar, you are right, but unfortunately the spec says that there should be a way
to specify the datasource at deployment. This can be done either by the user via
specifying some predefined name for the datasource (like jdbc/PU1DS) that is
retargeted to the actual datasource of choice at the necessary points of time.
Another option would be to either modify the existing persistence.xml on the fly
or add something like sun-persistence.xml for overrides (which is even worse).
This second option becomes even more complicated as persistence.xml can be
placed into the EAR's /lib directory, and we won't even unpack it on deployment,
right?
May be we should test and document the 1st solution (I wouldn't advise to change
jdbc/__default).

Comment by Tom Mueller [ 21/Jan/11 ]

This is a deployment issue at its heart. The capability needs to be provided via the asadmin and GUI interfaces, but it is the deployment logic that needs to support this capability.

Comment by Hong Zhang [ 10/Oct/12 ]

Reassign to JDBC team to see if it makes sense to provide this support through deploy command.

And retarget to future release as it's not a must for GlassFish 4.0.





[GLASSFISH-4128] ability to plugin custom implementations of various functionalities for connection pool Created: 08/Feb/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: V3
Fix Version/s: not determined

Type: New Feature Priority: Major
Reporter: Jagadish Assignee: Shalini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Dependency
blocks GLASSFISH-4147 Request prioritization in application... Open
Issuezilla Id: 4,128
Status Whiteboard:

v3-prd-item


 Description   

Expose datastructure, pool-wait-queue, pool resizing behaviour as interfaces for
multiple implementations.

Define pool life cycle, events, event listeners so that applications can listen
to these events, control pool behavior.



 Comments   
Comment by Jagadish [ 08/Feb/08 ]

tagging as v3-prd-item

Comment by Jagadish [ 05/Mar/08 ]

removing dependency

Comment by Jagadish [ 28/Dec/09 ]

Transferring to Shalini

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-4127] Import Connection pool config from Tomcat context.xml Created: 08/Feb/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: jdbc
Affects Version/s: V3
Fix Version/s: not determined

Type: New Feature Priority: Major
Reporter: Shalini Assignee: Shalini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 4,127
Status Whiteboard:

v3-prd-item


 Description   

Ability to import connection pool configuration from tomcat's context.xml



 Comments   
Comment by Shalini [ 08/Feb/08 ]

added as v3-prd-item

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-4124] Associate with thread Created: 08/Feb/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: jdbc
Affects Version/s: V3
Fix Version/s: not determined

Type: New Feature Priority: Major
Reporter: Shalini Assignee: Shalini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 4,124
Status Whiteboard:

v3-prd-item


 Description   

Associate multiple connections with a single thread as against single connection
with a single thread.



 Comments   
Comment by Shalini [ 08/Feb/08 ]

Added as v3-prd-item

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-7054] Ability to close all connections in a pool Created: 16/Jan/09  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: jdbc
Affects Version/s: 9.1peur2
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: trondstromme Assignee: Shalini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issuezilla Id: 7,054

 Description   

The ability to close all connections in a JDBC connection pool when disabling
the pool would be great as it frees up any resources the connections hold in the
database.
This should be available both from asadmin, the web interface and exposed as a
method on the MBean of the connection pool.



 Comments   
Comment by trondstromme [ 16/Jan/09 ]

added cc

Comment by Jagadish [ 28/Dec/09 ]

Transferring to Shalini

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-3205] Need "application aware" pools Created: 15/Jun/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: jdbc
Affects Version/s: V3
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: Alexis MP Assignee: Shalini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File prioritized-resource-scheduling.txt    
Issue Links:
Dependency
blocks GLASSFISH-4147 Request prioritization in application... Open
Issuezilla Id: 3,205
Status Whiteboard:

v3-prd-item


 Description   

Let's have the following scenario: application A, B and C would like to
use DB pool X. I would like to have a common DB connection pool, with
the following guaranties: A has at least 10, B has at least 5, C has at
least 5 "dedicated" connections, and the overall connection pool size is
below 50 connections. So the remaining 30 "undedicated" connection is
served on-demand for the applications.



 Comments   
Comment by jesper_soderlund [ 16/Nov/07 ]

Created an attachment (id=1260)
Feedback on larger scope than just database con. pools

Comment by Jagadish [ 08/Feb/08 ]

tagging as v3-prd-item

Comment by Jagadish [ 08/Feb/08 ]

targeted for v3

Comment by Jagadish [ 05/Mar/08 ]

removing dependency

Comment by Jagadish [ 28/Dec/09 ]

Transferring to Shalini

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-14547] Mysql ping fails when additional properties are not deleted Created: 09/Nov/10  Updated: 24/Feb/12

Status: Open
Project: glassfish
Component/s: jdbc
Affects Version/s: 3.1
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: shaline Assignee: Shalini
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: XML File domain.xml    
Issuezilla Id: 14,547
Tags: 3_1-release-note-added, 3_1-release-notes

 Description   

Build used: GFV3.1 nightly dated: 11/7
OS: Windows XP
Browser: IE8

When we keep all the additional properties for the Mysql pool ,and the values
for user, password and url fields, the ping fails. When we delete these
additional properties and keep only the User,Password and url properies, the
ping succeeds.

steps:
Copy mysql-connector-java-5.1.7-bin.jar to domain1/lib/ext and restart.
Create a JDBC connection pool as below:
datasource-classname="com.mysql.jdbc.jdbc2.optional.MysqlDataSource"
res-type="javax.sql.DataSource"
name="MyPool">
"url" value="jdbc:mysql://asqe-core2.sfbay.sun.com:3306/dbsmpl1"
"Password" value="dbpassword"
"User" value="dbuser"

Keep all the additional properties intact, and try Ping. it fails. delete them
and try ping again, it succeeds.



 Comments   
Comment by Anissa Lam [ 09/Nov/10 ]

Can you let us know what are the additional props and its value when the ping failed for you ?
If you do the ping through CLI, doees it work for you ?

Comment by shaline [ 09/Nov/10 ]

Created an attachment (id=5387)
domain.xml

Comment by Anissa Lam [ 09/Nov/10 ]

thanks for domain.xml.
Can you ping successfully using CLI ?

Comment by shaline [ 09/Nov/10 ]

ping fails even in CLI since the additional properties are added from admin
console. If we remove the additional properties , then ping succeeds even in
console,and CLI.

Comment by Anissa Lam [ 10/Nov/10 ]

those properties are whats given to us from backend. transferring to 'jdbc' for evaluation.

Comment by sumasri [ 11/Nov/10 ]

Transferring it to backend team.

Comment by Jagadish [ 11/Nov/10 ]

This behavior has been there since Application Server 8.x

Please refer issue 549 , there was a detailed discussion about MySQL driver
exposing all these attributes.
GlassFish will not have a control over these properties.

The only option we had was to make GUI show the standard properties and then in
another tab showing all properties.

StandardProperties =

{ "databaseName", "serverName", "port", "networkProtocol", "user", "password", "roleName", "datasourceName" }

;

Marking this as RFE.

As long as the user follows the documented list of properties (docs of
GlassFish), it works fine.
http://docs.sun.com/app/docs/doc/820-7692/gbsor?l=en&a=view

Anissa, let me know if its possible to change admin console screen to show
standard properties first (atleast for MySQL case alone) and then based on the
request from user, show all other properties, I can work on providing an API
which can be called by console.

Also refer the issue 3475 (enhancement)

Comment by Anissa Lam [ 11/Nov/10 ]

Its too late now to make this kind of UI change.
We can think about this after 3.1
thanks.

Comment by Scott Fordin [ 23/Mar/11 ]

Need more info to add issue to 3.1 Release Notes.

Comment by Shalini [ 23/Mar/11 ]

When a ping is done with all the properties mentioned in the domain.xml(attached) for mysql-pool, the following error message is got.

Ping failed Exception - Access denied to execute this method : setLargeRowSizeThreshold Please check the server.log for more details.

Workaround is to provide only the standard list of properties documented. The standard properties are "databaseName", "serverName", "port", "networkProtocol", "user", "password", "roleName", "datasourceName".

Comment by Scott Fordin [ 15/Apr/11 ]

Added issue to 3.1 Release Notes.

Comment by Shalini [ 25/Apr/11 ]

This is an RFE and could be addressed in 3.2. The solution for this is tricky as in, if only the standard properties are listed for all jdbc drivers, the user would have to look into the jdbc driver vendor documentation for the available properties and set each one of them by typing it manually. Its much easier to delete the properties that cause a failure before trying a ping rather than adding lot of properties manually.

Comment by Nazrul [ 24/Feb/12 ]

Configuring a MySQL pool needs just these 6 properties, may be even a few less.

<property name="URL" value="jdbc:mysql://127.0.0.1:3306/blahr"></property>
<property name="portNumber" value="3306"></property>
<property name="databaseName" value="blah"></property>
<property name="serverName" value="blah.dyndns.org"></property>
<property name="user" value="blah"></property>
<property name="password" value="xxx"></property>

Currently, we show a long list of properties. It would be good if we can show standard properties for all JDBC drivers to make user experience better. We may display the entire set of properties introspected from JDBC driver in advanced tab.





[GLASSFISH-18394] Datasource properties not passed to database connection (Oracle database) Created: 22/Feb/12  Updated: 23/Feb/12

Status: Open
Project: glassfish
Component/s: jdbc
Affects Version/s: 3.1.1
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Thomas Andres Assignee: Shalini
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Java Archive File ojdbc6.jar     PNG File Screen shot 2012-02-22 at 14.16.27.png    

 Description   

I've recently discovered a jdbc performance issue with Queries that fetch many (thousands to millions) of small records from a oracle database. To solve that, the property "defaultRowPrefech" can be specified to increase the prefetch from 10 to some more reasonable value.

This worked well, when I opened a connection directly and also on a jboss server. When I changed the jdbc resource pool in my glassfish, this property apparently wasn't passed to the database connection.

I debugged the problem and saw that the configuration was available in the datasource. I got a DataSource40 containing a DSManagedConnectionFactory with a DataSourceSpec. There was a map that contained amongst other infos:
19=setURL#jdbc:oracle:thin:@zapf.ergon.ch:1521:ZAPF##setlanguage#english##setdefaultRowPrefetch#1000##
There are exactly the properties specified in the admin console. (apart from the "set" prefixes)

However, the database connection created from this datasource still had defaultRowPrefetch set to 10.

Am I doing something wrong and is there some other way this should be configured or is this a bug, that this attribute isn't passed to the database connection?



 Comments   
Comment by Thomas Andres [ 22/Feb/12 ]

added screenshot of the configuration in the admin console

Comment by Shalini [ 23/Feb/12 ]

Could you attach the jdbc connection pool configuration from your domain.xml file? I am speficifically looking for the datasource classname you set and also the jdbc driver you are using.

Comment by Thomas Andres [ 23/Feb/12 ]

The configuration is:

    <jdbc-connection-pool validation-table-name="CUSTOMER" 
datasource-classname="oracle.jdbc.pool.OracleDataSource" max-pool-size="300" wrap-jdbc-objects="false" 
res-type="javax.sql.DataSource" steady-pool-size="5" allow-non-component-callers="true" 
name="newom_dev3_pool" is-connection-validation-required="true" 
validate-atmost-once-period-in-seconds="300">
      <property name="URL" value="jdbc:oracle:thin:@zapf.ergon.ch:1521:ZAPF"></property>
      <property name="user" value="NEWOM_DEV3"></property>
      <property name="password" value="password"></property>
      <property name="language" value="english"></property>
      <property name="defaultRowPrefetch" value="1000"></property>
    </jdbc-connection-pool>

The jdbc driver is the standard ojdbc6.jar. I'll attach the version I'm using in case there are different versions of this I'm not aware of.

Comment by Thomas Andres [ 23/Feb/12 ]

used oracle driver

Comment by Shalini [ 23/Feb/12 ]

As per http://docs.oracle.com/cd/A97335_02/apps.102/a83724/oraperf2.htm :

"Use the setDefaultRowPrefetch() method of your OracleConnection object
to set the default number of rows to prefetch, passing in an integer that
specifies the desired default. "

The properties user, password are passed in the jdbc connection pool as
properties of the OracleDataSource object, whereas the defaultRowPrefetch
should be set on an OracleConnection object.

Alternatively, while getting the connection in your application, you could
unwrap the connection got, to get the OracleConnection object and then
set this property on the connection object. GlassFish provides an ability to
unwrap a connection object :

http://docs.oracle.com/cd/E19798-01/821-1752/ggrum/index.html

As per the above, this is not an issue.

Comment by Thomas Andres [ 23/Feb/12 ]

I strongly disagree. I'm well aware, that I can set the property from the code on the connection or statement. The point of doing this in the datasource is to make it easily configurable without code changes. Also to make the default apply regardless of who (my code, JPA, ...) opens the connection.
I did the same in a JBoss server that we use for an older version of our application and had no problem setting a property in the datasource to pass it along.

Also from your reference:

Equivalently, instead of calling setDefaultRowPrefetch(), you can set the defaultRowPrefetch Java property if you use a Java Properties object in establishing the connection. See "Specifying a Database URL and Properties Object".

In my opinon, the properties on the data source should also be used as if I use DriverManager.getConnection() with properties. Why do you provide a way to add additional properties for a datasource that are then ignored? There is no reason to treat username, password any different from any other property if all properties are passed on to create the connection. The only thing that is a property here and needs to be treated differently is the URL. I would prefer to see the URL parameter moved to the general configuration tab (don't think there is much chance to get a connection without an URL anyway) and pass all additional properties on to the driver to create the database connection. That is much cleaner and provides flexible, driver independent configuration.

If you don't pass along properties, you should scrap the additional properties entirely and just provide a static UI with fixed fields that you actually support.

Comment by Shalini [ 23/Feb/12 ]

The OracleDataSource.java does not have a method called setDefaultRowPrefetch(). However, the defaultRowPrefetch could be set as a Properties object on a setConnectionProperties() method. In GlassFish currently, we support only key value pairs as additional properties. For example, you could set MaxStatements property directly in additional properties.

We would consider this as an RFE, to parse the Properties object passed thereby reflecting this in database connection.





[GLASSFISH-15968] JPA/JPQL - Bitwise support Created: 13/Feb/11  Updated: 10/Oct/12

Status: Open
Project: glassfish
Component/s: jdbc
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: nirzohar Assignee: Shalini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: JPA, JPQL

 Description   

Support for bitwise type for JPA.
JPA spec not define bitwise operation for JPQL.



 Comments   
Comment by Tom Mueller [ 10/Oct/12 ]

Putting in jdbc component as we don't have a component for JPA.





[GLASSFISH-15732] need to be able to specify GlassFish specific pool attributes in @DataSourceDefinition Created: 28/Jan/11  Updated: 18/Oct/12

Status: Open
Project: glassfish
Component/s: jdbc
Affects Version/s: None
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: Jagadish Assignee: Shalini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: ee7ri_cleanup_deferred

 Description   

@DataSourceDefinition has specific attributes defined for pool management.
GlassFish's jdbc-connection-pool exposes more pool characteristics/features that can be exposed (supported) by @DataSourceDefinition so that it can be tuned.

eg:
Ability to set lazy-connection-enlistment, association.
Ability to define exact "resource-type" in case of the "className" defined in @DataSourceDefinition implements multiple DataSource types ie., javax.sql.DataSource, javax.sql.ConnectionPoolDataSource, javax.sql.XADataSource
eg: DataDirect's MS SQL datasource-classname is an implementation of all the three types which makes it impossible to specify the type that an user want to use.



 Comments   
Comment by Tom Mueller [ 18/Oct/12 ]

Marking the fix version field as "future-release". This is based on an evaluation by John, Michael, and Tom WRT to the PRD for the Java EE 7 RI/SDK. This issue was deemed to not be a P1 for that release. If this is in error or there are other reasons why this RFE should be targeted for the Java EE 7 RI/SDK release, then change the fix version field back to an appropriate build.





[GLASSFISH-17433] Maximum-pool-size is involved in the behavior of unpooled connections Created: 17/Oct/11  Updated: 08/Dec/11

Status: Open
Project: glassfish
Component/s: jdbc
Affects Version/s: 4.0
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: ito_m Assignee: Shalini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All



 Description   

Maximum-pool-size in pool settings is described on GlassFish Server Administration Console Reference below.

The maximum number of connections in the pool. The default value is 32.

However this functionality always sets an upper limit to the number of connections regardless of the pooling attribute value which is enabled or disabled although almost any other attributes such as initial-and-minimum-pool-size has no effect on unpooled connections.

I think this spec may confuse users and can be a frequent cause of incorrect use. It is because the more likely scenario where unpooled mode will be selected is the case a user would like to use connections pooled by a JDBC driver. In this case, not only a JDBC driver but also an application server redundantly restricts the connection size by default due to the default value of maximum-pool-size(32).

I would like to confirm the reason why maximum-pool-size is effective on even unpooled mode. Besides, I believe we should avoid adopting an option which lets users change maximum-pool-size manually so that they can make sure maximum-pool-size is greater than the upper limit set on the JDBC driver. I think it difficult for users to understand the relationship between maximum-pool-size and unpooled mode.

Therefore I would suggest either one of the following improvements if it is acceptable.
1. Remove the corresponding codes controlling the maximum size of connections when the pooling attribute is specified as disabled.

com.sun.enterprise.resource.pool.UnpooledResource.java
       private synchronized boolean incrementPoolSize(){
        if(poolSize >= maxPoolSize) // These are the condition
            return false;           // for maximum-pool-size.
        poolSize++;
        return true;
    }

2. Prepare a value of maximum-pool-size which allows users to create unlimited connections and switch to this special value automatically when the pooling attribute is specified as disabled. They can also specify another value as maximum-pool-size consciously afterwards if needed.



 Comments   
Comment by Shalini [ 08/Dec/11 ]

Though the names (steady-pool-size/max-pool-size) may sound
inappropriate for the "pooling=false" option, these are used to limit
the concurrent number of connections usage ie., a pool can serve upto
"max-pool-size" number of connections at any point in time. We do not
allow unlimited connections to be acquired as that can potentially bring
down the entire DB/EIS server.

We could come up with a better naming mechanism for steady-pool-size and max-pool-size when connection pooling is turned off.





[GLASSFISH-16472] Monitoring support for @DataSourceDefinition Created: 27/Apr/11  Updated: 02/Dec/11

Status: Open
Project: glassfish
Component/s: jdbc
Affects Version/s: 4.0
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Shalini Assignee: Shalini
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Existing implementation of @DataSourceDefinition is realized internally as a jdbc-resource and jdbc-connection-pool. It would be useful to expose monitoring statistics of @DataSourceDefinition (ie., the jdbc-connection-pool monitoring statistics) to users. Following monitoring hierarchy could be used to display the statistics according to the scope in which the @DataSourceDefinition is defined.

server.<application-name>.datasource-definition.java:global/<global-scoped-dsd>
server.<application-name>.datasource-definition.java:app/<app-scoped-dsd>
server.<application-name>.datasource-definition.<module-name>.java:module/<module-scoped-dsd>
server.<application-name>.datasource-definition.<module-name>.<component-name>.java:comp/<component-scoped-dsd>

Note :
1) For component scoped @DSD in web bundle descriptors, following convention will be used
server.<application-name>.<module-name>.datasource-definition.java:comp/<component-scoped-dsd>

2) For applications that are not .ear, <module-name> will not be applicable.






[GLASSFISH-16471] Granular SQL tracing Created: 27/Apr/11  Updated: 02/Dec/11

Status: Open
Project: glassfish
Component/s: jdbc
Affects Version/s: 4.0
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Shalini Assignee: Shalini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Need to add functionality to provide a more granular tracing of SQL queries. All Connection related SQL traces should be logged as INFO messages.

When "javax.enterprise.resource.sqltrace" log level is set to INFO, only operations related to Connection will be traced in the server.log. The default value FINE should continue to support tracing of Connection, Statement, PreparedStatement and CallableStatement.






[GLASSFISH-16723] provide better error message for missing JDBC resources Created: 24/May/11  Updated: 24/May/11

Status: Open
Project: glassfish
Component/s: jdbc
Affects Version/s: 3.1
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Nazrul Assignee: Shalini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Based on the following forum thread: http://forums.java.net/node/805271

We are not providing clear error message when a JDBC resource is missing during web application loading.

Since this is a common mistake where users forgets to create the necessary resources before deploying the application, lets try to provide clear error message.






[GLASSFISH-19451] Allow JDBC driver to be loaded from application archive Created: 15/Dec/12  Updated: 23/Feb/14

Status: Open
Project: glassfish
Component/s: jdbc
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: Shalini
Resolution: Unresolved Votes: 7
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: datasource, ear, embedded, jdbc, war

 Description   

As one of the few application servers, GlassFish does not allow a JDBC driver to be loaded from a .war or .ear (see http://henk53.wordpress.com/2012/06/30/the-state-of-datasourcedefinition-in-java-ee). Instead, the driver is required to be stored inside the GlassFish installation directory.

Especially for applications that use an embedded database and an application scoped datasource (specifically those using @DataSourceDefinition), this is not convenient. Those applications can be coded to be almost portable, with the exception that for GlassFish a jar (the JDBC driver) has to be copied from the archive to the AS installation directory.

I would like to ask for the ability to load said JDBC driver directly from an application archive such as .war and .ear.



 Comments   
Comment by Darious3 [ 20/Dec/12 ]

You can now include glassfish-resources.xml in your war, where you can define JDBC resources. These resources have a lifetime scoped to the WAR (created and destroyed when the WAR is deployed/undeployed).

This behavior really should apply to the JDBC driver as well.

Comment by Darious3 [ 04/Apr/13 ]

Has anything happened for this yet?

Comment by arjan tijms [ 16/Dec/13 ]

This seems to have been "silently" fixed in GlassFish 4. The following unit test in the Java EE samples project shows this: https://github.com/javaee-samples/javaee7-samples/blob/master/jpa/datasourcedefinition/src/test/java/org/javaee7/jpa/datasourcedefinition/DataSourceDefinitionTest.java

This test addresses the exact use case this issue is about and puts the JDBC driver into the application archive. The test passes on a stock (embedded) GlassFish 4.

Maybe it should also be tested on a standalone GlassFish 4, but hopefully this shouldn't make any difference.

Comment by martinandersson.com [ 23/Feb/14 ]

The github example you give inject the datasource. I must use a persistence.xml file to declare the persistence unit that relies on my @DataSourceDefinition. With this requirement I can't get my application to work. Another way for me since Java EE 7 is to use the default data source, but then of course, my application still don't deploy deploy and work properly since GlassFish doesn't start his Derby database automatically. For me, I refuse to manually copy-paste jar files to the glassfish installation direction as much as I refuse to manually start the derby database. I can happily do that for a production environment, but until then, as what is my issue now, I'm using Arquillian to do real proper integration tests.

Comment by arjan tijms [ 23/Feb/14 ]

I must use a persistence.xml file to declare the persistence unit that relies on my @DataSourceDefinition. With this requirement I can't get my application to work.

You're most likely being affected by this bug: GLASSFISH-20944

The driver seems to load, but then because of a timing issue of some sorts, or maybe a scoping issue, the JPA boot code can't locate the datasource. Very unfortunate indeed! (please vote for that issue if you think it impacts you). See also JAVAEE_SPEC-30

my applications still don't deploy deploy and work properly since GlassFish doesn't start his Derby database automatically. For me, I refuse to manually copy-paste jar files to the glassfish installation direction as much as I refuse to manually start the derby database.

I agree. This shouldn't be required. I logged issue JAVAEE_SPEC-34 for precisely this a short while ago. There's a corresponding GlassFish specific issue at GLASSFISH-20666

If you care for getting those solved, please vote for them as well

Comment by martinandersson.com [ 23/Feb/14 ]

Thank you Arjan for your feedback, you seem to be a real good spirit. Keep it up! Yeah I did vote for those other issues =)

Comment by reza_rahman [ 23/Feb/14 ]

I think this could be a pretty nice community contribution .





[GLASSFISH-19248] Dynamic Proxy generation in GlassFish JDBC connection pool Created: 26/Oct/12  Updated: 26/Oct/12

Status: Open
Project: glassfish
Component/s: jdbc
Affects Version/s: future release
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Shalini Assignee: Shalini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In GlassFish, as of now, when SQL tracing feature is enabled, a dynamic proxy is created for all java.sql.Statement objects.

This new feature must provide an extension of providing the dynamic proxy for other java.sql.* objects viz., java.sql.ResultSet and java.sql.<ALL_DATA_TYPES>.

A common pre/post/exception handling logic inside the dynamic proxy is implemented in the dynamic proxy for all invocations on every java.sql.* object. This feature should allow for a complete tracing in addition to the calls that are vendor specific, reducing the overhead while debugging and exception handling.

When any java.sql.* object is unwrapped, the dynamic proxy will not be used and hence tracing will be skipped for that object.






[GLASSFISH-19245] FIXED type of statement caching support in glassfish jdbc connection pool Created: 26/Oct/12  Updated: 26/Oct/12

Status: Open
Project: glassfish
Component/s: jdbc
Affects Version/s: future release
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Shalini Assignee: Shalini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Statement caching feature allows for an application to cache highly-used statements, prepared statements and callable statements during start-up processing.

A new statement cache eviction strategy FIXED maintains the statement cache size based on an existing attribute statement-cache-size unless the cache is manually cleared. The statements executed by applications on the connection are cached until the statement-cache-size is reached. When additional statements are used, they are not cached.

A new attribute statement-cache-type should be introduced which will indicate the type of statement cache type to be used by applications. Default value of this attribute is LRU (Least Recently Used) where the least recently used statement is removed when a new statement is used.






[GLASSFISH-19246] Removing Infected connections feature in glassfish jdbc connection pool Created: 26/Oct/12  Updated: 26/Oct/12

Status: Open
Project: glassfish
Component/s: jdbc
Affects Version/s: future release
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Shalini Assignee: Shalini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Remove infected connections is a feature to configure whether or not unwrapping implies that a connection should be considered infected and not reused. When a connection is unwrapped, this connection is marked for deletion on returning to the connection pool. When an application closes a logical connection, the underlying physical connection is not returned to the connection pool. Instead, the physical connection is closed and recreated.

This parameter must be applicable only if an application gets a connection from the connection pool and does an unwrap() on that object. The unwrap() method returns a vendor specific connection to the caller which might leave the connection pool in an inconsistent state.

The new attribute remove-infected-connections must remove such connections from the connection pool. Default value of this attribute should be false.






[GLASSFISH-19244] Seconds to trust support in GlassFish jdbc connection pool Created: 26/Oct/12  Updated: 26/Oct/12

Status: Open
Project: glassfish
Component/s: jdbc
Affects Version/s: future release
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Shalini Assignee: Shalini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Seconds to trust is an enhancement to validate-atmost-once attribute that indicates the number of seconds within a connection usage that the connection is trusted as valid and connection validation test is skipped.

Based on the last validated or last time usage of the connection, if the time interval between two connection acquisitions is less than seconds-to-trust configuration, the connection validation must be skipped.

Seconds to trust feature can be enabled by setting the connection pool configuration attribute validate-atmost-once. Default value of this attribute is zero, indicating that the seconds to trust feature is turned off.






[GLASSFISH-19243] Validation table name enhancement in GlassFish jdbc connection pool Created: 26/Oct/12  Updated: 26/Oct/12

Status: Open
Project: glassfish
Component/s: jdbc
Affects Version/s: future release
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Shalini Assignee: Shalini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The attribute validation-table-name in glassfish jdbc-connection-pool accepts only a table name as input. This must be enhanced to accept as input, a string "SQL" followed by a space and sql code.

This feature is only applicable when is-connection-validation-required attribute is set to true and connection-validation-method is table.

This feature provides a means of performing connection validation test when there is a sql code specified.






[GLASSFISH-19242] Fatal error code handling Created: 26/Oct/12  Updated: 26/Oct/12

Status: Open
Project: glassfish
Component/s: jdbc
Affects Version/s: future release
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Shalini Assignee: Shalini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Fatal error codes is a new feature that indicates that the back-end database with which the datasource communicates is no longer accessible on a connection. The connection is marked invalid and is removed from the connection pool. This feature ensures to keep bad connections out of the pool.

Pre-defined error codes for Oracle JDBC driver and Derby should be added. Additionally, a mechanism for adding error codes for other JDBC drivers should be provided.

A new attribute called fatal-error-codes should be introduced for glassfish jdbc-connection-pool that can take in user input of fatal error codes. When any of these error codes occur, the connection is marked as bad.






[GLASSFISH-19007] Missed query timeout while connection validation by table query Created: 16/Aug/12  Updated: 16/Aug/12

Status: Open
Project: glassfish
Component/s: jdbc
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: evgeniya Assignee: Shalini
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Hi,

See please
http://java.net/projects/glassfish/sources/svn/content/trunk/main/appserver/jdbc/jdbc-ra/jdbc-core/src/main/java/com/sun/gjc/spi/ManagedConnectionFactory.java?rev=53670:

protected void isValidByTableQuery(java.sql.Connection con, String tableName) throws ResourceException {
...
final String statement = "SELECT COUNT FROM " + tableName;
stmt = con.prepareStatement(statement);
rs = stmt.executeQuery();
...
}

It would be great to have query timeout here (with some default value, that can be changed, say, by some JVM option). (http://docs.oracle.com/javase/6/docs/api/java/sql/Statement.html#setQueryTimeout(int))

Actually, we had server outage in our production because of lack of this timeout (see details here: http://perfstories.wordpress.com/2012/05/15/yet-another-hanging-java-net-socketinputstream-socketread0/)

Thank you,

Evgeniya






[GLASSFISH-19006] Default values of essential vendor specific properties in domain.xml Created: 16/Aug/12  Updated: 16/Aug/12

Status: Open
Project: glassfish
Component/s: jdbc
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: evgeniya Assignee: Shalini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Hi,
In particular, I mean, at least:
a) socket timeouts for Oracle clients (sun.net.client.defaultConnectTimeout, Dsun.net.client.defaultReadTimeout);
b) socket timeouts for Oracle JDBC Driver(oracle.jdbc.ReadTimeout).

(they could be set as JVM properties, -D<property name>=<value in millisec, say, 60000>)

These are really essential properties. We have a lot of emergencies because we didn't know them. Actually, we used Glassfish 2.1.1, but I didn't find notes about these options in further versions of Glassfish too.
I would say there should be default values for these options in domain.xml.

These properties are really important, as they could prevent our Glassfish server outage, see for example, here http://perfstories.wordpress.com/2012/08/14/be-aware-of-sun-oracle-networking-properties/.

Thank you,

Evgeniya






[GLASSFISH-16956] A statement timeout is not set on executing SQL statements in connection validation and init SQL Created: 05/Jul/11  Updated: 02/Dec/11

Status: Open
Project: glassfish
Component/s: jdbc
Affects Version/s: 4.0
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: ito_m Assignee: Shalini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All



 Description   

The Statement timeout is provided to guarantee that abnormally long running queries will time out explicitly.
However the current implementation seems not to support timeout for connection validation SQLs (in case of table and custom validations) or init SQLs executed automatically when acquiring connections from pool.

Connection validation implementation corresponds to ManagedConnectionFactory#isValid(ManagedConnection) of jdbcra.
Init SQL implementation corresponds to ManagedConnection#executeInitSql(String) of jdbcra.
Each method creates a statement using a physical connection of a jdbc driver directly and executes SQLs without calling setQueryTimeout().

I think it desirable to support timeout for SQLs of these functionalities although I assume a hanging state rarely occurs as a result of executing them, especially because select statements for validation are simple and light.






[GLASSFISH-5699] list the pools in a sorted fashion Created: 27/Aug/08  Updated: 19/Jan/11

Status: Open
Project: glassfish
Component/s: jdbc
Affects Version/s: V3
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: sankarpn Assignee: Shalini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 5,699

 Description   

v3-prelude 8/27

bash-3.00# asadmin list-jdbc-connection-pools -u admin --passwordfile /password.txt
oracle_type4_pool
microsoft_dd_pool
sybase_dd_pool
sybase_inet_pool
__TimerPool
microsoft_inet_pool
mysql-pool
postgresql_type4_pool
microsoft_jtds_pool
db2_dd_pool
microsoft_sqlserver2000_pool
microsoft_sqlserver2005_pool
DerbyPool
oracle_inet_pool
javadb_type4_pool
sybase_jconn_pool
db2_jcc_pool
oracle_dd_pool

Command list-jdbc-connection-pools executed successfully.

In the above list-jdbc-connection-pools output the order of the pools are
scattered. Instead if the pools are listed in alphabetical order that would be a
good list to look for the desired pool name.



 Comments   
Comment by Tom Mueller [ 19/Jan/11 ]

Please evaluate this RFE for inclusion in 3.2, a future release, or close it.





Generated at Mon Jan 23 22:14:38 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.