Annotating a Resource Adapter

Annotations 

@Connector :

@ConnectionDefinition(s) :

@AdministeredObject :

@Activation :

@ConfigProperty :

Connector annotations support in GlassFish :

Deployment descriptor elements and equivalent annotations:

References:

• Java EE 6 Preview SDK

• Java EE Connector Architecture 1.6 Specification

Templates to create JDBC Connection Pool & Resource

How to use :

Templates :

glassfish

1) Admin console

2) CLI

3) Using AMX :

Sample Output :

References :

• GlassFish V2

• dotted-names

• AMX

To create a jdbc-connection-pool in GlassFish, templates are provided for various databases
in GF_INSTALL_DIR/lib/install/templates/resources/jdbc

"javadb_type4_datasource.xml" is for jdbc-3.0 datasource.

eg:
Copy the file and modify the "datasource-classname" to "org.apache.derby.jdbc.ClientDataSource40"
and "res-type" to "javax.sql.DataSource"
Specify appropriate values to connection parameters eg (user, password, hostname, databasename etc.,)
and name of jdbc connection pool and jdbc resource.

FAQ:

Bundles Used :

• GlassFish V2 b44

• JDK 1.6

• JDBC 4.0

• JavaDB (Derby 10.2.2.0) bundled with GlassFish

glassfish

Connection Pool manages a pool of connections and serves the user requests quickly as creating a new
connection for each user request will take longer time. Since the connections are pooled, it is possible
that a connection may become invalid or stale, i.e., database server may set the connection state to
closed because of network failure or database might have been restarted. In such scenario, if the application
retrieves a connection from connection pool, failure will occur indicating that the connection is no more valid.


To circumvent stale connections issue, connection pool property "is-connection-validation-required" can be set
to true. This flag indicates the connection pool to validate the connection for every request by the application.
Validating a connection ensures that the connection is in healthy state. If the connection validation fails,
connection will be removed from the pool and the application will get valid connection. [Pool will either return the
next valid connection or create a new connection]. Thus validation ensures that every getConnection() request
by the application  will be served by a valid connection.

To set validation :
eg: DerbyPool

Following command will list resources by name "DerbyPool"

By default, the validation mode is "auto-commit". Auto-commit property of the connection to be validated
will be set & reset by the validation logic. Most of the jdbc-drivers cache the "auto-commit" value of the
connection and hence actual validation (connecting to database) does not happen.

Instead, setting table-based validation will ensure that validation happens properly. A valid table name need to
be provided, validation logic will issue a query on this table. If the connection is stale, this query will fail and
hence will be removed from the pool.

To set Table-based validation :

Sometimes, database restart may result in all the connections in the pool to be invalid.
In such a case, first get connection after restart will result in validating a connection, removing it from the pool,
validating the next connection and so on. Eventually all connections will be validated, removed from the pool
and pool will be reinitialized.

Following property "fail-all-connections" will ensure that when one of the connections become valid, pool will be
reinitialized, ie., all connections will be destroyed and initialized again.

Above property need to be set only in cases where there are more possibilities of database restarts/failures, as
all connections are dropped and recreated for a single connection validation failure.

References

glassfish

 JDBC Connection Pool & Resource can be created in multiple ways.

• Admin Console
• CLI
• Using sun-resources.xml templates
• Creating Connection Pool & Resource programmatically

1) Admin Console

Admin console provides user intuitive interface to create a connection pool & resource for database access.
a) Copy the jdbc driver that will be used for database connectivity, to GLASSFISH_INSTALL/domains/<domainname>/lib/ext or
add the jdbc-driver path to "classpath-prefix" and restart application server.

b) Using Admin console, Common Tasks > create jdbc connection pool



c) Provide a name for the connection pool, select the resource type, select the database vendor and press Next



d) Console will list the the default pool settings and also the properties of datasource class provided by the vendor.




e) Fill the values for datasource properties, eg: servername, user, password, URL, databasename etc., and press Finish
   
f) Pool will be created



g) To check whether the values provided for datasource for database connectivity are valid and works fine, press Ping.
Ping will use these properties and try to establish a connection.



This connection pool need to be associated with a jdbc-resource.

h) To create a jdbc-resource that will be used by the application :
Resources > Jdbc Resources


i) Press New

j) provide the jndi name for the resource and the pool with which the resource need to be associated.




k) Press OK, jdbc-resource will be created.

2) Using CLI

3) Using sun-resources.xml templates

4) Creating Connection Pool & Resource programmatically

References :

glassfish

Using Sequoia with GlassFish

Bundles used :

Setup :

Installation of Sequoia :

Sequoia Controller :

Configuration of virtual database:

Configuring individual database nodes for data replication :

Configuring recovery log table :

Configuring the Backuper :

Controller configuration :

Starting the Sequoia controller :

20:31:21,629 INFO controller.core.Controller Sequoia  controller (2.10.6)
20:31:21,694 INFO controller.core.Controller Loading configuration file: config/controller/hetero-distributed-1.xml
20:31:21,791 INFO controller.core.Controller JMX is enabled
20:31:21,820 INFO controller.core.Controller Starting JMX server on host: 127.0.0.1
20:31:22,185 INFO backup.backupers.DerbyEmbeddedBackuper DerbyEmbeddedBackuper backup compression is set to true
20:31:22,223 INFO backend.DatabaseBackend.localhost1 Adding connection manager for virtual user "jdbc"
20:31:22,229 INFO backend.DatabaseBackend.localhost2 Adding connection manager for virtual user "jdbc"
20:31:22,234 INFO backend.DatabaseBackend.localhost3 Adding connection manager for virtual user "jdbc"
20:31:25,899 INFO sequoia.controller.recoverylog Creating recovery log table: RECOVERY
20:31:26,011 INFO sequoia.controller.recoverylog Creating checkpoint table: CHECKPOINT
20:31:26,160 INFO sequoia.controller.recoverylog Creating backend table: BACKEND
20:31:26,227 INFO sequoia.controller.recoverylog Creating dump table: DUMP
20:31:26,410 INFO controller.RequestManager.heterodb Request manager will parse requests with the following granularity: TABLE
20:31:26,417 INFO controller.virtualdatabase.heterodb Using Hedera properties file:/hedera_jgroups.properties
-------------------------------------------------------
GMS: address is127.0.0.1:32771
-------------------------------------------------------
20:31:31,211 INFO controller.virtualdatabase.heterodb Group heterodb connected to Member(address=/127.0.0.1:32771, uid=heterodb)
20:31:31,211 INFO controller.virtualdatabase.heterodb First controller in group heterodb
20:31:31,422 INFO sequoia.controller.recoverylog Checking recovery log consistency
20:31:31,533 WARN controller.virtualdatabase.heterodb Cannot enable backend localhost1 from a known state. Resynchronize this backend by restoring a dump.
20:31:31,536 WARN controller.virtualdatabase.heterodb Cannot enable backend localhost2 from a known state. Resynchronize this backend by restoring a dump.
20:31:31,538 WARN controller.virtualdatabase.heterodb Cannot enable backend localhost3 from a known state. Resynchronize this backend by restoring a dump.
20:31:31,539 INFO controller.core.Controller Adding VirtualDatabase heterodb
20:31:31,553 INFO controller.core.Controller Waiting for connections on 0.0.0.0:25322
20:31:31,562 INFO controller.core.Controller Controller started on 2007.03.08 10 at08:31:31 PM IST
20:31:31,562 INFO controller.core.Controller Controller 127.0.0.1:25322 ready, listening to requests ...

Initializing the nodes using the Sequoia console:

Launching the Sequoia controller console
Initializing Controller module...
Initializing VirtualDatabase Administration module...
Initializing SQL Console module...
Sequoia driver (Sequoia core v2.10.6) successfully loaded.

localhost:1090 > admin heterodb
Virtual database Administrator Login > admin
Virtual database Administrator Password > 
Ready to administrate virtual database heterodb

heterodb(admin) > initialize localhost1 force
Virtual Database heterodb has been successfully initialized from backend localhost1

heterodb(admin) > initialize localhost2 force
Virtual Database heterodb has been successfully initialized from backend localhost2

heterodb(admin) > enable localhost1
Enabling backend localhost1 from its last known checkpoint

heterodb(admin) > enable localhost2 
Enabling backend localhost2 from its last known checkpoint

Sample application :

Customer CMP application :

heterodb(admin) > disable localhost2
Disabling backend localhost2 with automatic checkpoint.
heterodb(admin) > 

Sequoia Controller will have similar logs :

22:33:13,236 INFO  controller.RequestManager.heterodb All activity is suspended for heterodb
22:33:13,361 INFO  controller.virtualdatabase.heterodb Checkpoint disable 
localhost2-127.0.0.1:25322-20070308223313132+0530 was stored
22:33:13,364 INFO  controller.virtualdatabase.heterodb Disabling backend localhost2,
 waiting for current transaction to complete on this
backend
22:33:13,384 INFO  sequoia.controller.connection 5 connections freed on
"jdbc:derby:heterodb1;Password=APP;User=APP;databaseName=heterodb1;create=true;"
22:33:13,509 INFO  controller.virtualdatabase.heterodb Backend localhost2 is now disabled
22:33:13,509 WARN  controller.virtualdatabase.heterodb No information has been found for remote controller
Member(address=/127.0.0.1:32773, uid=heterodb)
22:33:13,509 WARN  controller.virtualdatabase.heterodb Updating backend list with unknown backend localhost2
 disabled on controller
Member(address=/127.0.0.1:32773, uid=heterodb)

heterodb(admin) > disable localhost1
Disabling backend localhost1 with automatic checkpoint.

heterodb(admin) > enable localhost2
Enabling backend localhost2 from its last known checkpoint

Multiple controllers :

Steps in brief :

localhost:1090 > admin
Virtual Database Name > heterodb
Virtual database Administrator
Login > admin
Virtual database Administrator Password > 
Ready to administrate virtual database heterodb

heterodb(admin) > backup localhost1 localhost1.bkp DerbyEmbeddedBackuper /home/jagadish/Desktop
Backend login for backup process > admin
Backend password for backup process > 
Backup backend localhost1 in dump file localhost1.bkp

heterodb(admin) > show controllers
heterodb is hosted by 2 controller(s):
127.0.0.1:1091       
127.0.0.1:1090

heterodb(admin) > transfer dump localhost1.bkp 127.0.0.1:1091 nocopy
Transferring dump localhost1.bkp to controller 127.0.0.1:1091...
Done

 




heterodb(admin) > restore backend localhost3 localhost1.bkp.2
Backend login for restore process> admin
Backend password for restore process > 
Restoring backend localhost3 with dump localhost1.bkp.2
heterodb(admin) > restore backend localhost4 localhost1.bkp.2
Backend login for restore process> admin
Backend password for restore process > 
Restoring backend localhost4 with dump localhost1.bkp.2

heterodb(admin) > disable localhost2
Disabling backend localhost2 with automatic checkpoint.
heterodb(admin) > disable localhost1
Disabling backend localhost1 with
automatic checkpoint.

References :

Technorati Tags: glassfish

Connection Sharing in GlassFish Application Server

When multiple connections x and y acquired by an application are used within a transaction scope, application server will provide shared connection behavior when the following set of properties are satisfied.

• x and y are collocated in a single Java Virtual Machine process address space.
• x and y are using a single transactional resource manager.
• x and y have identical properties.
• x and y are marked as shareable.
• x and y are used within a container-managed or bean-managed transaction scope.

In GlassFish, connections from different jdbc-resources using same connection-pool can be shared.

Ex:

When multiple connection requests to same data-source happen within a transaction, application server may re-use the connection already acquired as a part of the transaction.
Let us consider the following scenario :

	Tx Scope Begins
		get Connection1
		do DB operation
		get Connection2
		do DB operation
	Tx Scope Ends

Suppose, connection-2 has to be acquired from the same data-source as that of connection-1, application server may re-use the physical connection of connection-1.

How do I enable/disable Connection Sharing ?

By specifying the following highlighted property in deployment descriptor (web.xml / ejb-jar.xml). Default value is Shareable.

 <resource-ref>
        <res-ref-name>jdbc/EmployeeAppDB</res-ref-name>
        <res-type>javax.sql.DataSource</res-type>
        <res-auth>Container</res-auth>
        <res-sharing-scope>Shareable</res-sharing-scope>
    </resource-ref>

To disable sharing:

        <res-sharing-scope>Unshareable</res-sharing-scope>

Note : For Local Transactions, only shareable scope is applicable.

Connection Sharing in BMPs

a) Container Managed Transaction:

   ( <transaction-type>Container</transaction-type>)
		 BMP-Bean-1
			businessMethod(){   // Transaction attribute "Required"
				con1 = dataSource.getConnection();  
				doDBOperation();
				bean2 = lookupBean2;
				bean2.businessMethod();
				con1.close();
			}

		BMP-Bean-2
			businessMethod(){ // Transaction Attribute "Required"
				con2 = dataSource.getConnection(); // same data-source as that of con1 in bean-1
				doDBOperation();
				con2.close();
  			}

During Bean2's method call, connection sharing happens. Application server first acquires a free connection from the connection pool. During connection enlistment, connection association happens which will map the ManagedConnection (and hence physical connection) of con-1 to con-2. Thus DBOperation happens through same physical connection (connection sharing).

What happens to the actual Physical Connection acquired by conn-2 ?

By the end of transaction, physical connection of con-1 is dissociated from conn-2 and conn-2 is mapped back with its actual physical connection. The purpose of this connection association and dissociation can be seen in the following sample.

b)Bean Managed Transaction

		   (<transaction-type>Bean</transaction-type>)
			businessMethod(){   
				UserTransaction uTx = entityContext.getUserTransaction(); 
				try{
					uTx.begin();
					con1 = dataSource.getConnection(); 
					doDBOperation() using con1;

					con2 = dataSource.getConnection(); 
					doDBOperation() using con2; //using physical connection of conn-1, connection sharing.
					uTx.commit();
				}
				catch(SQLException sqle){
					uTx.rollback();
				}
					con1.close();
					doDBOperation() using con2; // using actual physical connection,  no sharing involved.
					con2.close();
			}

After commit/rollback, con2 is associated back with its actual physical connection. Thus during doDBOperation() after the UserTransaction scope, actual physical connection of conn-2 is used.

How do I know that connection-sharing has actually happened?

In the sample above, dataSource ( com.sun.appserv.jdbc.DataSource ) has a method to get the physical connection.

To get the physical connection,

			Connection pc1 = dataSource.getConnection(con1);
			Connection pc2 = dataSource.getConnection(con2);

pc1, pc2 can be retrieved within and outside the scope of a transaction and compared.

• Picture shows connections' state in Application Server, Resource Adapter (Physical Connection), within and outside the transaction scope.
• Log shows the connection objects' hash-code value within and outside the transaction scope.

Few interesting scenarios to see whether connection sharing happens or not is,

			a) 
				con1 = dataSource.getConnection();  
				UserTransaction uTx = entityContext.getUserTransaction(); 
				uTx.begin();
					con2 = dataSource.getConnection();  
 					doDBOperation() using connection-1
 					doDBOperation() using connection-2
				uTx.commit();
				con1.close();
				con2.close();
			
			b)
				con1 = dataSource.getConnection();  
				con2 = dataSource.getConnection();  
				UserTransaction uTx = entityContext.getUserTransaction(); 
				uTx.begin();
 					doDBOperation() using connection-1
 					doDBOperation() using connection-2
				uTx.commit();
				con1.close();
				con2.close();
 

Are there any restrictions when connections are used in sharing scope?

Yes, When connection sharing is enabled, certain properties should not be modified. Suppose connection-1's property is changed and when sharing happens, connection-2 will have the modified property. Application Server will throw SharingViolationException. More details can be found in the J2EE Connector Architecture 1.5 Specification, section 7.9 - Transaction Management > Connection Sharing.

Technorati Tags: glassfish