has to be installed separately.
Native libraries
and append (or prepend) that location to the system's
PATH environment variable.
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.
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..
The latter must only be set if chronological logging is enabled by setting LogSwitch to "on".
(only if desired)
(only if desired)
"testapp" example-application
(optional)
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.
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).
- Databases
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
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
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
Methods begin(), commit() and rollback() are relayed to the BDB environment by TransactionImpl.
MappedRecord mr = rf.createMappedRecord("arbitrary_name_or_empty_string");
Class clazz = Class.forName(is[0]); // currently only 1 is returned
InteractionSpecImpl ispec = (org.sourceforge.bdbadapter.cci.InteractionSpecImpl) clazz.newInstance();
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);
cciCon.close();