Installation (binary release)

J2EE SDK 1.3.1 J2EE SDK 1.4 beta

If chronological logging is wanted, the corresponding resource adapter
has to be installed separately.

Berkeley DB
Native libraries
Copy all Berkeley DB native libraries to some location
and append (or prepend) that location to the system's
PATH environment variable.

Windows: libdb41.dll and libdb_java41.dll
Both these dll's are included in the RAR archive even though Sun's SDKs
don't support installation from there. Copying them to an apt location and
adjusting the PATH must be done manually.

On Unix:

Server security settings
This policy file has to be edited so the adapter has sufficient rights.
An example policy-file is included in the RAR archive. Editing or copying
this file must be done manually before the SDK's server is started..

Editing adapter properties
In the RAR archive, extract and then edit the file /META-INF/ra.xml according to your system. The most important properties to edit are DbEnvPath andLogDirectory.
The latter must only be set if chronological logging is enabled by setting LogSwitch to "on".

RAR deployment
deploytool -deployConnector bdbadapter.rar [hostname] deploytool -deployModule bdbadapter.rar [-server hostname]

RAR undeployment
(only if desired)
deploytool -undeployConnector bdbadapter.rar [hostname] deploytool -undeployModule bdbadapter [-server hostname]

Creating the ConnectorFactory JNDI entry
j2eeadmin -addConnectorFactory bdbadapter_factory bdbadapter.rar j2eeadmin -addConnectorFactory bdbadapter_factory bdbadapter

Removing the ConnectorFactory JNDI entry
(only if desired)
j2eeadmin -removeConnectorFactory bdbadapter_factory j2eeadmin -removeConnectorFactory bdbadapter_factory

EAR deployment of
"testapp" example-application
deploytool -deploy testapp.ear [hostname]
deploytool -deployModule testapp.ear [-server hostname]


Weblogic 7.x

Berkeley DB native libraries
All native libraries are included in the RAR file and their target-location is specified in the WL-specific deployment descriptor weblogic-rar.xml.
During deployment, Weblogic copies them from the RAR to the chosen target-location.
Still, the PATH environment variable must be pointed to that location manually by editing the start-scripts for the Weblogic-server.


In order to reach a solid and stable version for this resource-adapter and considering the complexity of transactions,
it is very helpful to have a chronologicallog of what's going on during application- and adapter-operations. For this, a
simple logging-framework is provided.
All J2EE components using the bdbadapter (for example servlets and EJB's) can output log-information  via a separate
resource-adapter (logger.rar). The bdbadapter itself logs with the special class "SimpleLogger"
(one resource-adapter using another resource-adapter doesn't make a lot of sense...).
At any time during after operations, the log-files can be viewed with a separate application called "logview", which is a
very simple JDK 1.4.x Swing-Application consisting of a scrollable JTable.
Logview lists all log-outputs chronologicallyin a table. In this table, each different "log-source"
(for example a BMP-Entity Bean or the class TransactionImpl in the adapter itself) has its own column,
so that viewed side-by-side, the history of what occured when and where becomes obivous.
Additionally, important transaction-related events in the bdbadapter are color-coded.

Remember: This logging-functionality serves exclusively to find operational problems quickly during testing and should
be switched off or dropped entirely, if bdbadapter reaches production-quality (see also property "LogSwitch" above).

"inner workings"

  • Databases
Berkeley DB databases to be used by resource adapter clients must be declared in a properties-file.
This properties-file's name and location is itself one of the resource adapters properties and must be specified in the container-specific resource adapter deployment descriptors.
Each key in this properties-file is a logical name for the database (which is the value).
It is this logical name that a client specifies when executing a CCI interaction on the resource adapter.

  • BDB environment

At the center of things is one BDB environment (see BDB docs).
The class AdapterEnv extends class DbEnv (see BDB Java API) and therefore represents this one environment.
Please refer to the BDB documentation for an explanation what exactly a BDB environment is and why it is needed to operate on transactional BDB databases.

BDB environments have many configurable settings.
A subset of these settings are mapped one-to-one to the resource adapters propeties and can be configured as needed by either editing the XML deployment descriptors or via an application server specific admin-console.
When an instance of  AdapterEnv is constructed, these settings are passed on to DbEnv's constructor and various setters.

AdapterEnv is a singleton. It holds and keeps track of all opened BDB databases.
One very important task for AdapterEnv is to close the environment as soon as the last BDB database is closed, as seen in the method AdapterEnv.closeDatabase().
The singleton instance is created and the environment is opened when the first ManagedConnection is requested by the application server by calling the method ManagedConnectionFactoryImpl.createManagedConnection().

Because more often than not more than just one ManagedConnection can be bound to the same physical BDB database, the class DbHandle encapsulates one unique Db instance and in turn keeps track of how many ManagedConnection instances are holding a reference to it. Similar to the environment, the encapsulated Db instance is closed when the last ManagedConnection using that database is destroyed.

As opening and closing the BDB environment maps very well to the lifecycle of a JCA 1.5 resource adapter, this will probably be done differently in future JCA 1.5 versions of the adapter. Unfortunately JCA 1.0 lacks such a lifecycle.

What is lacking in both JCA specifications is how a resource adapter is to be loaded by the server.
For example, Weblogic employs separate classloaders for each resource adapter, which means that AdapterEnv can only be a singleton per resource adapter instance.

  • Connection management

Each ManagedConnection keeps a set of all configured databases to be used by the various resource adapter clients.
These database instances are instances of class Db from the BDB Java API.
Also, as specified by JCA, a ManagedConnection holds and keeps track of all connection handles, handed out to client-components using this resource adapter.

  • Local transactions

The picture to the left is not exact as it does not depict the class SpiLocalTransactionImpl which, for now, is just a dumb wrapper around TransactionImpl.
Methods begin(), commit() and rollback() are relayed to the BDB environment by TransactionImpl.

CCI Interface usage

Getting a ConnectionFactory
ConnectionFactory cf = (ConnectionFactory) new InitialContext().lookup("your_jndi_name_here");

Getting a Connection
Connection cciCon = cf.getConnection();

Creating a Mapped Record
RecordFactory rf = cf.getRecordFactory();
MappedRecord mr = rf.createMappedRecord("arbitrary_name_or_empty_string");

Creating the InteractionSpec
String[] is = cf.getMetaData().getInteractionSpecsSupported();
Class clazz = Class.forName(is[0]); // currently only 1 is returned
InteractionSpecImpl ispec = (org.sourceforge.bdbadapter.cci.InteractionSpecImpl) clazz.newInstance();

Executing an Interaction ispec.setDbName("customers"); // this is a logical name, used as key in the properties-file
ispec.setFunctionName(org.sourceforge.bdbadapter.cci.InteractionSpecImpl.FUNCTION_PUT); // other operations available here!
mr.put(MappedRecordImpl.KEY, "bdb_key_value");
mr.put(MappedRecordImpl.DATA, "bdb_data_value");
Interaction interaction = cciCon.createInteraction();

interaction.execute(ispec, mr);

Closing interaction.close();