Problems with TM in ejbCreate()

[Dino Di Cola <di...@yahoo.it>]

Dear all,
I encountered some problems with Transaction
Management porting my J2EE application from Ora9ias
9.0.2 to Ora9ias 9.0.3 platform.
I tried to reproduce the problem with a simple J2EE
application made up of a test stateless session bean
with a single business method.
This very simple J2EE application is deployed
successfully both in Ora9ias 9.0.2 and Ora9ias 9.0.3.
The business method (test_odmg()) can be successfully
invoked by a RMI client on the Ora9ias 9.0.2
deployment.
On the Ora9ias 9.0.3 deployment however I get the
following error:

The following exception has been catched: Error in
ejbCreate(): No external transaction found; nested
exception is:
        org.odmg.TransactionNotInProgressException: No
external transaction found
	com.evermind.server.rmi.OrionRemoteException: Error
in ejbCreate(): No external transaction found
        at
com.evermind.server.ejb.StatelessSessionEJBHome.getContextInstance(StatelessSessionEJBHome.java:267)
        at
OJBTest_ODMG_StatelessSessionBeanWrapper52.test_odmg(OJBTest_ODMG_StatelessSessionBeanWrapper52.java:83)
        at java.lang.reflect.Method.invoke(Native
Method)
        at
com.evermind.server.rmi.RMICallHandler.run(RMICallHandler.java:119)
        at
com.evermind.server.rmi.RMICallHandler.run(RMICallHandler.java:48)
        at
EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:803)
        at java.lang.Thread.run(Thread.java:479)
	at connection to c99-012.prirm.pride.it/10.2.21.8 as
admin
        at
com.evermind.server.rmi.RMIConnection.EXCEPTION_ORIGINATES_FROM_THE_REMOTE_SERVER(RMIConnection.java:1558)
        at
com.evermind.server.rmi.RMIConnection.invokeMethod(RMIConnection.java:1511)
        at
com.evermind.server.rmi.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:55)
        at
com.evermind.server.rmi.RecoverableRemoteInvocationHandler.invoke(RecoverableRemoteInvocationHandler.java:22)
        at
com.evermind.server.ejb.StatelessSessionRemoteInvocationHandler.invoke(StatelessSessionRemoteInvocationHandler.java:50)
        at __Proxy4.test_odmg(Unknown Source)
        at
it.enidata.psv.ejb.client.TestOJB_ODMG.main(TestOJB_ODMG.java:45)

        Nested exception is:
	org.odmg.TransactionNotInProgressException: No
external transaction found
        at
org.apache.ojb.odmg.JTATxManager.registerTx(Unknown
Source)
        at
org.apache.ojb.odmg.TransactionImpl.begin(Unknown
Source)
        at
org.apache.ojb.odmg.ImplementationJTAImpl.beginInternTransaction(Unknown
Source)
        at
org.apache.ojb.odmg.ImplementationJTAImpl.registerOpenDatabase(Unknown
Source)
        at
org.apache.ojb.odmg.DatabaseImpl.open(Unknown Source)
        at
it.enidata.psv.ejb.account.OJBTest_ODMGBean.init(OJBTest_ODMGBean.java:99)
        at
it.enidata.psv.ejb.account.OJBTest_ODMGBean.ejbCreate(OJBTest_ODMGBean.java:41)
        at
OJBTest_ODMGHome_StatelessSessionHomeWrapper53.callCreate(OJBTest_ODMGHome_StatelessSessionHomeWrapper53.java:145)
        at
com.evermind.server.ejb.StatelessSessionEJBHome.getContextInstance(StatelessSessionEJBHome.java:254)
        at
OJBTest_ODMG_StatelessSessionBeanWrapper52.test_odmg(OJBTest_ODMG_StatelessSessionBeanWrapper52.java:83)
        at java.lang.reflect.Method.invoke(Native
Method)
        at
com.evermind.server.rmi.RMICallHandler.run(RMICallHandler.java:119)
        at
com.evermind.server.rmi.RMICallHandler.run(RMICallHandler.java:48)
        at
EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:803)
        at java.lang.Thread.run(Thread.java:479)
	at connection to c99-012.prirm.pride.it/10.2.21.8
        at
com.evermind.server.rmi.OrionRemoteException.receive(OrionRemoteException.java:130)
        at
com.evermind.server.rmi.RMIConnection.handleMethodInvocationResponse(RMIConnection.java:1673)
        at
com.evermind.server.rmi.RMIConnection.run(RMIConnection.java:532)
        at
com.evermind.server.rmi.RMIConnection.run(RMIConnection.java:275)
        at
EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:797)
        at java.lang.Thread.run(Thread.java:484)

The error arises in the ejbCreate() as soon as the
db.open() is invoked. 
- If I move the OJB initialization into the business
method (leaving the EJB as "stateless") the error
disappears.
- If I change the deployment descriptor from
"stateless" to "stateful" (leaving the OJB
initialization into the ejbCreate()) the error
disappears.
What is the rationale behind this behaviour?

Here below you will find 
- the source code of the test session bean
- the deployment descriptor
- the OJB.properties

Any assitance in the matter would be great. 
Thanks in advance.

Regards,


Dino.
--

***********************************************************************
**** Source code for the session bean
*********************************
***********************************************************************
public class OJBTest_ODMGBean implements SessionBean {
	
  private SessionContext sessionContext;
  private static final String DEF_DATABASE_NAME =
"dsOJB";
  
  private Implementation odmg;
  private Database db;
  
  public OJBTest_ODMGBean() {}
  
  public void ejbActivate() {
  }
  
  public void ejbPassivate() {
  }
  
  public void ejbCreate() throws CreateException {
  	try {
  		init();
  	} catch (InitException e) {
  		throw new CreateException(e.getMessage());
  	}  	
  }

  private void init() throws InitException{
  	Logger logger =
Logger.getLogger("psv.j2ee.testing");
  	logger.debug("OJBTest_ODMGBean - test_odmg():
begin");

	logger.debug("OJBTest_ODMGBean - test_odmg():
initializing ODMG connection [BEGIN]");
 
	logger.debug("OJBTest_ODMGBean - test_odmg():
OJB.getInstance()");
	odmg = OJB.getInstance();  	 
	logger.debug("OJBTest_ODMGBean - test_odmg(): found
Implementation instance [" + odmg + "]");
	
	logger.debug("OJBTest_ODMGBean - test_odmg():
odmg.newDatabase()");
	db = odmg.newDatabase();
  	 
	try {
		logger.debug("OJBTest_ODMGBean - test_odmg(): open
new database " + db + " using databaseName name " +
DEF_DATABASE_NAME);
		db.open(DEF_DATABASE_NAME,
Database.OPEN_READ_WRITE);            
	} catch (ODMGException e) {
		logger.error("OJBTest_ODMGBean - test_odmg():
Database open failed", e);
		throw new InitException(e.getMessage());
	} 
	
	logger.debug("OJBTest_ODMGBean - test_odmg():
initializing ODMG connection [END]");	
  }
  
  public void ejbRemove() {
  	Logger logger =
Logger.getLogger("psv.j2ee.testing");
  	logger.debug("OJBTest_ODMGBean - ejbRemove():
closing ODMG connection [BEGIN]");
  	try {
  		logger.debug("OJBTest_ODMGBean - ejbRemove():
db.close(): " +  db);
  		if (db != null) db.close();
  	} catch (ODMGException e) {
  		logger.error("OJBTest_ODMGBean - ejbRemove():
closing of database failed", e);
  	}  	
  	db = null;
  	odmg = null;
  	logger.debug("OJBTest_ODMGBean - ejbRemove():
closing ODMG connection [END]"); 
  }
  
  public void setSessionContext(SessionContext
sessionContext) {
    this.sessionContext = sessionContext;
  }
  
  public String test_odmg() throws
java.rmi.RemoteException {
  	Logger logger =
Logger.getLogger("psv.j2ee.testing");  	
  	logger.debug("OJBTest_ODMGBean - test_odmg():
end");
	SimpleDateFormat simpleDateFormat = new
SimpleDateFormat("dd.MM.yyyy hh:mm:ss");
    	return "OJBTest_ODMGBean - test_odmg(): done [" +

simpleDateFormat.format(Calendar.getInstance().getTime())
+ "]";
  }
  
}


***********************************************************************
**** Deployment descriptor
********************************************
***********************************************************************
<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar>
  <enterprise-beans>
    <session>
      <ejb-name>OJBTest_ODMG</ejb-name>
     
<home>it.enidata.psv.ejb.account.OJBTest_ODMGHome</home>
     
<remote>it.enidata.psv.ejb.account.OJBTest_ODMG</remote>
     
<ejb-class>it.enidata.psv.ejb.account.OJBTest_ODMGBean</ejb-class>
      <session-type>Stateless</session-type>
      <transaction-type>Container</transaction-type>
    </session>
  </enterprise-beans>
  <assembly-descriptor>
    <container-transaction>
      <method>
        <ejb-name>OJBTest_ODMG</ejb-name>
        <method-name>*</method-name>
      </method>
      <trans-attribute>NotSupported</trans-attribute>
    </container-transaction>
  </assembly-descriptor>
</ejb-jar>

***********************************************************************
**** OJB.properties
***************************************************
***********************************************************************
#<!--
#/* Copyright 2002-2004 The Apache Software Foundation
# *
# * Licensed under the Apache License, Version 2.0
(the "License");
# * you may not use this file except in compliance
with the License.
# * You may obtain a copy of the License at
# *
# *     http://www.apache.org/licenses/LICENSE-2.0
# *
# * Unless required by applicable law or agreed to in
writing, software
# * distributed under the License is distributed on an
"AS IS" BASIS,
# * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND,
either express or implied.
# * See the License for the specific language
governing permissions and
# * limitations under the License.
# */
#-->
# OJB.properties -- configuration of the OJB runtime
environment 
# Version: 1.0
# (c) 2001, 2002, 2003 Apache Software Foundation
# Author: Thomas Mahler and many others
# @version $Id: OJB.properties,v 1.2 2004/07/19
13:52:56 d.dicola Exp $
#
#----------------------------------------------------------------------------------------
# repository file settings
#----------------------------------------------------------------------------------------
# The repositoryFile entry tells OJB to use this file
as as its standard mapping
# repository. The file is looked up from the
classpath.
#
repositoryFile=repository.xml
#
# If the useSerializedRepository entry is set to true,
OJB tries to load a
# serialized version of the repository for performance
reasons.
# if set to false, OJB always loads the xml file.
# Setting this flag to true will accelerate the
startup sequence of OJB.
# If set to true changes to the repository.xml file
will only be detected
# after maually deleting the repository.xml.serialized
file.
useSerializedRepository=false
#
# If Repository serialization is used the entry
serializedRepositoryPath defines the
# directory where the Repository is written to and
read from.
# this entry is used only when the
useSerializedRepository flag is set to true
#
serializedRepositoryPath=.
#
#----------------------------------------------------------------------------------------
# PersistenceBrokerFactory / PersistenceBroker
#----------------------------------------------------------------------------------------
# The PersistenceBrokerFactoryClass entry decides
which concrete
# PersistenceBrokerFactory implemention is to be used.
PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl
# If in managed environment *only* the PB-api was used
it's recommended to use this factory
# to enable the PersistenceBroker instances to
participate in the JTA transaction. This makes
# e.g. PBStateListener work properly in managed
environments.
#PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactorySyncImpl
#
#
# The PersistenceBrokerClass entry decides which
concrete PersistenceBroker
# implementation is to be served by the
PersistenceBrokerFactory.
# This is the singlevm implementation:
PersistenceBrokerClass=org.apache.ojb.broker.core.PersistenceBrokerImpl
#
# This is an implementation that uses Prevayler
(prevayler.sf.net) as the persistent storage.
# Using this implementation OJB works as a simple
OODBMS
#PersistenceBrokerClass=org.apache.ojb.broker.prevayler.PBPrevaylerImpl
#
#----------------------------------------------------------------------------------------
# PersistenceBroker pool
#----------------------------------------------------------------------------------------
# PersistenceBroker pool configuration
# This pool uses the jakarta-commons-pool api.
# There you can find things described in detail.
#
# maximum number of brokers that can be borrowed from
the
# pool at one time. When non-positive, there is no
limit.
maxActive=100
#
# controls the maximum number of brokers that can sit
idle in the
# pool (per key) at any time. When non-positive, there
is no limit
maxIdle=-1
#
# max time block to get broker instance from pool,
after that exception is thrown.
# When non-positive, block till last judgement
maxWait=2000
#
# indicates how long the eviction thread should sleep
before "runs" of examining
# idle objects. When non-positive, no eviction thread
will be launched.
timeBetweenEvictionRunsMillis=-1
#
# specifies the minimum amount of time that an broker
may sit idle
# in the pool before it is eligable for eviction due
to idle time.
# When non-positive, no object will be dropped from
the pool due
# to idle time alone (depends on
timeBetweenEvictionRunsMillis > 0)
minEvictableIdleTimeMillis=1000000
#
# specifies the behaviour of the pool when broker
capacity is
# exhausted (see maxActive above)
# 0 - fail
# 1 - block
# 2 - grow
whenExhaustedAction=0
#
#
#----------------------------------------------------------------------------------------
# ConnectionFactory / Default ConnectionPool
#----------------------------------------------------------------------------------------
# The ConnectionFactoryClass entry determines which
kind of ConnectionFactory
# is to be used within org.apache.ojb as connection
factory.
# A ConnectionFactory is responsible for creating
# JDBC Connections. Current version ships four
implementations:
#
# 1. ConnectionFactoryNotPooledImpl
#    No pooling, no playing around.
#    Every connection request returns a new
connection,
#    every connection release close the connection.
# 2. ConnectionFactoryPooledImpl
#    This implementation supports connection pooling.
# 3. ConnectionFactoryDBCPImpl
#    Using the jakarta-DBCP api for connection
management, support
#    connection- and prepared statement-pooling,
abandoned connection handling.
# 4. ConnectionFactoryManagedImpl
#    Connection factory for use within managed
environments - e.g. JBoss.
#    Every obtained DataSource was wrapped within OJB
(and ignore
#    e.g. con.commit() calls within OJB).
#    Use this implementation e.g if you use
Datasources from an application server.
#
# Use the OJB performance tests to decide, which
implementation is best for you.
# The proper way of obtaining a connection is
configured in
# JDBCConnectionDescriptor entries in the
repository.xml file.
# If want a more fine grained control of each
connection pool used by OJB,
# take a look at the repository.dtd, there was a
possibility to override
# this default connection factory entry in each
JDBCConnectionDescriptor.
#
#ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl
#ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryNotPooledImpl
ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryManagedImpl
#ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryDBCPImpl
#
#
#----------------------------------------------------------------------------------------
# ConnectionManager
#----------------------------------------------------------------------------------------
# The ConnectionManagerClass entry defines the
ConnectionManager implemementation to be used
ConnectionManagerClass=org.apache.ojb.broker.accesslayer.ConnectionManagerImpl
#
#
#----------------------------------------------------------------------------------------
# SqlGenerator
#----------------------------------------------------------------------------------------
# The SqlGeneratorClass entry defines the SqlGenerator
implemementation to be used
SqlGeneratorClass=org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl
#
#
#----------------------------------------------------------------------------------------
# IndirectionHandler
#----------------------------------------------------------------------------------------
# The IndirectionHandlerClass entry defines the class
to be used by OJB's proxies to
# handle method invocations
#
IndirectionHandlerClass=org.apache.ojb.broker.core.proxy.IndirectionHandlerDefaultImpl
#
#----------------------------------------------------------------------------------------
# ListProxy
#----------------------------------------------------------------------------------------
# The ListProxyClass entry defines the proxy class to
be used for collections that
# implement the java.util.List interface.
#
ListProxyClass=org.apache.ojb.broker.core.proxy.ListProxyDefaultImpl
#
#----------------------------------------------------------------------------------------
# SetProxy
#----------------------------------------------------------------------------------------
# The SetProxyClass entry defines the proxy class to
be used for collections that
# implement the java.util.Set interface.
#
SetProxyClass=org.apache.ojb.broker.core.proxy.SetProxyDefaultImpl
#
#----------------------------------------------------------------------------------------
# CollectionProxy
#----------------------------------------------------------------------------------------
# The CollectionProxyClass entry defines the proxy
class to be used for collections that
# do not implement java.util.List or java.util.Set.
#
CollectionProxyClass=org.apache.ojb.broker.core.proxy.CollectionProxyDefaultImpl
#
#----------------------------------------------------------------------------------------
# StatementManager
#----------------------------------------------------------------------------------------
# The StatementManagerClass entry defines the
StatementManager implemementation to be used
StatementManagerClass=org.apache.ojb.broker.accesslayer.StatementManager
#
#
#----------------------------------------------------------------------------------------
# StatementsForClass
#----------------------------------------------------------------------------------------
# The StatementsForClassClass entry defines the
StatementsForClass implemementation to be used
# to implement cached statements.
StatementsForClassClass=org.apache.ojb.broker.accesslayer.StatementsForClassImpl
#
#
#----------------------------------------------------------------------------------------
# JdbcAccess
#----------------------------------------------------------------------------------------
# The JdbcAccessClass entry defines the JdbcAccess
implemementation to be used
JdbcAccessClass=org.apache.ojb.broker.accesslayer.JdbcAccessImpl
#
#
#----------------------------------------------------------------------------------------
# Object cache
#----------------------------------------------------------------------------------------
# The ObjectCacheClass entry tells OJB which concrete
ObjectCache
# implementation is to be used as standard cache.
# Its also possible to override this entry adding
object-cache elements
# on jdbc-connection-descriptor level and
# per class-descriptor in repository file. More info
see documentation.
#
ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheDefaultImpl
#ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheEmptyImpl
#ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCachePerBrokerImpl
#ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheJCSPerClassImpl
#ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCachePerClassImpl
#
#
# This property is only relevant if the per
class-descriptor object-cache
# declaration was used in conjunction with metadata
runtime changes.
# If set 'flase' the class name of the object is used
# to find a per class ObjectCache implementation.
# If set 'true' the ObjectCacheDescriptor instance is
used as key to
# find a per class ObjectCache, this enables to use
different ObjectCache
# instances for the same class.
descriptorBasedCaches=false
#
#
# Use CacheFilters to do filter operations before
caching methods were
# called. Build your own filter class by implementing
org.apache.ojb.cache.CacheFilter.
# It is possible to use a arbitrary number of
CacheFilters, but this slows
# down the performance of the cache, thus handle with
care.
#
# - org.apache.ojb.broker.cache.CacheFilterClassImpl
# allows filtering of classes
# - org.apache.ojb.broker.cache.CacheFilterPackageImpl
# allows filtering of packages
# More info see Javadoc of the according classes.
# Set a comma separated list of CacheFilter.
#ObjectCacheFilter=org.apache.ojb.broker.cache.CacheFilterClassImpl,org.apache.ojb.broker.cache.CacheFilterPackageImpl
#
#----------------------------------------------------------------------------------------
# Locking
#----------------------------------------------------------------------------------------
# The LockManagerClass entry tells OJB which concrete
LockManager
# implementation is to be used.
LockManagerClass=org.apache.ojb.odmg.locking.LockManagerDefaultImpl
#
# The LockMapClass entry tells OJB which concrete
LockMap
# implementation is to be used.
# If OJB is running on multiple concurrent clients it
is recommended
# to use the RemoteLockMapImpl. It guarantees to
provide
# Lockmanagement across multiple JVMs.
# This Implemenation relies on a Servlet based
Lockserver. To use it you have to
# deploy the ojb-lockserver.war into a Servlet engine.
# and you have to set the Property LockServletUrl to
point to this servlet.
# (see LockServletUrl section below).
# If OJB is running in a single JVM (e.g. in a desktop
app, or in a servlet
# engine) it is save to use the InMemoryLockMapImpl.
Using it will result
# in a large performance gain.
#LockMapClass=org.apache.ojb.odmg.locking.RemoteLockMapImpl
LockMapClass=org.apache.ojb.odmg.locking.InMemoryLockMapImpl
#
# The LockTimeout entry defines the maximum time in
milliseconds
# that a lock may be hold. Defaults to 60000 = 1
minute
LockTimeout=60000
#
# The ImplicitLocking entry defines if implicit lock
acquisition is
# to be used. If set to true OJB implicitely locks
objects to ODMG
# transactions after performing OQL queries.
# If implicit locking is used locking objects is
recursive, that is
# associated objects are also locked.
# If ImplicitLocking is set to false, no locks are
obtained in OQL
# queries and there is also no recursive locking.
ImplicitLocking=true
#ImplicitLocking=false
#
#
# The LockServletUrl entry points to the Lockserver
servlet.
# This Servlet is addressed by all distributed JVMs if
the RemoteLockMapImpl
# is used.
LockServletUrl=http://127.0.0.1:8080/ojb-lockserver
#
#
# The LockAssociations entry defines the behaviour for
the OJB
# implicit locking feature. If set to WRITE (default)
acquiring a write-
# lock on a given object x implies write locks on all
objects associated
# to x. If set to READ implicit read-locks are
acquired.
# Acquiring a read-lock on x thus allways results in
implicit read-locks
# on all associated objects.
#LockAssociations=READ
LockAssociations=WRITE
#
#
#----------------------------------------------------------------------------------------
# OQL / SQL settings
#----------------------------------------------------------------------------------------
# The OqlCollectionClass entry defines the collection
type returned
# from OQL queries. By default this value is set to
DListImpl.
# This will be good for most situations as DList
allows maximum flexibility
# in a ODMG environment. See also section 'ODMG
settings'.
# Using DLists for large resultsets may be bad for
application performance.
# For these scenarios you can use ArrayLists or
Vectors.
# Important note: the collections class to be used
MUST implement the
# interface
org.apache.ojb.broker.ManageableCollection.
#
OqlCollectionClass=org.apache.ojb.odmg.collections.DListImpl_2
#
OqlCollectionClass=org.apache.ojb.broker.util.collections.ManageableArrayList
#
OqlCollectionClass=org.apache.ojb.broker.util.ManageableVector
#
# The SqlInLimit entry limits the number of values in
IN-sql statement,
# -1 for no limits. This hint is used in Criteria.
SqlInLimit=200
#
#
#----------------------------------------------------------------------------------------
# ODMG settings
#----------------------------------------------------------------------------------------
# Specify the used base class for ODMG API
# - ImplementationDefaultImpl is the default class
# - ImplementationJTAImpl is for use in managed
environments like J2EE conform
# Application Server
#
#ImplementationClass=org.apache.ojb.odmg.ImplementationDefaultImpl
ImplementationClass=org.apache.ojb.odmg.ImplementationJTAImpl
#
#
# Specify the used tx handling.
# - LocalTxManager use if you want the transaction to
be associated by a thread
# - JTATxManager use if you want the transaction to be
associated via the Transaction
# manager that is in your application server.
#
#OJBTxManagerClass=org.apache.ojb.odmg.LocalTxManager
OJBTxManagerClass=org.apache.ojb.odmg.JTATxManager
#
#
# Used ODMG collection implementation classes
# (e.g. when do a Implementation#newDlist() call)
#
# org.odmg.DList implementation class
DListClass=org.apache.ojb.odmg.collections.DListImpl_2
#DListClass=org.apache.ojb.odmg.collections.DListImpl
#
# org.odmg.DArray implementation class
DArrayClass=org.apache.ojb.odmg.collections.DListImpl_2
#DArrayClass=org.apache.ojb.odmg.collections.DListImpl
#
# org.odmg.DMap implementation class
DMapClass=org.apache.ojb.odmg.collections.DMapImpl
#
# org.odmg.DBag implementation class
DBagClass=org.apache.ojb.odmg.collections.DBagImpl
#
# org.odmg.DSet implementation class
DSetClass=org.apache.ojb.odmg.collections.DSetImpl
#
#
#----------------------------------------------------------------------------------------
# Meta data / mapping settings
#----------------------------------------------------------------------------------------
# The PersistentFieldClass property defines the
implementation class
# for PersistentField attributes used in the OJB
MetaData layer.
# By default the best performing attribute/refection
based implementation
# is selected (PersistentFieldDirectAccessImpl).
#
# - PersistentFieldDirectAccessImpl
#   is a high-speed version of the access strategies.
#   It does not cooperate with an AccessController,
#   but accesses the fields directly. Persistent
#   attributes don't need getters and setters
#   and don't have to be declared public or protected
# - PersistentFieldPrivilegedImpl
#   Same as above, but does cooperate with
AccessController and do not
#   suppress the java language access check.
# - PersistentFieldIntrospectorImpl
#   uses JavaBeans compliant calls only to access
persistent attributes.
#   No Reflection is needed. But for each attribute
xxx there must be
#   public getXxx() and setXxx() methods.
# - PersistentFieldDynaBeanAccessImpl
#   implementation used to access a property from a
#   org.apache.commons.beanutils.DynaBean.
# - PersistentFieldAutoProxyImpl
#   for each field determines upon first access how to
access this particular field
#   (directly, as a bean, as a dyna bean) and then
uses that strategy
#
PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDirectAccessImpl
#PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldPrivilegedImpl
#PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldIntrospectorImpl
#PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDynaBeanAccessImpl
#PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldAutoProxyImpl
#
#
#----------------------------------------------------------------------------------------
# Component Intercepting for Profiling and Tracing
#----------------------------------------------------------------------------------------
# By enabling an InterceptorClass all OJB components
will use
# this Interceptor. Interceptors allow advanced
tracing and Profiling
# of all component method calls.
# This is currently an experimental feature useful
only for OJB kernel developers.
#
#InterceptorClass=org.apache.ojb.broker.util.interceptor.TracingInterceptor
#
#----------------------------------------------------------------------------------------
# Transaction Management and assocation
#----------------------------------------------------------------------------------------
# (optional, only used when OJB runs within managed
environments)
# To praticipate in JTA transaction OJB needs access
to the underlying transaction manager.
# The TransactionManager is acquired in different ways
dependent on the application server.
# The JTATransactionManagerClass property allows you
to specify the class that implements
# the proper behaviour for finding the transaction
manager. Only use when OJBTxManagerClass
# is set to a factory that uses the application server
transaction manager
# (org.apache.ojb.odmg.JTATxManager)
#
# JBoss Transaction Manager Factory
#JTATransactionManagerClass=org.apache.ojb.broker.transaction.tm.JBossTransactionManagerFactory
# Weblogic Transaction Manager Factory
#JTATransactionManagerClass=org.apache.ojb.broker.transaction.tm.WeblogicTransactionManagerFactory
# WebSphere transaction manager factory
#JTATransactionManagerClass=org.apache.ojb.broker.transaction.tm.WebSphereTransactionManagerFactory
# Orion transaction manager factory
JTATransactionManagerClass=org.apache.ojb.broker.transaction.tm.OrionTransactionManagerFactory
# SunOne transaction manager factory
#JTATransactionManagerClass=org.apache.ojb.broker.transaction.tm.SunOneTransactionManagerFactory
# JOnAs transaction manager factory
#JTATransactionManagerClass=org.apache.ojb.broker.transaction.tm.JOnASTransactionManagerFactory
#
#
#----------------------------------------------------------------------------------------
# Logging
#----------------------------------------------------------------------------------------
# The LoggerClass entry tells OJB which concrete
Logger
# implementation is to be used.
#
# Commons-logging
#LoggerClass=org.apache.ojb.broker.util.logging.CommonsLoggerImpl
# log4j based logging
LoggerClass=org.apache.ojb.broker.util.logging.Log4jLoggerImpl
# OJB's own simple looging support
#LoggerClass=org.apache.ojb.broker.util.logging.PoorMansLoggerImpl
LoggerConfigFile=log4j.properties
#
# The LogLevel entries tells OJB which LogLevels are
active
# for the different loggers used within OJB
# Loglevels: DEBUG < INFO < WARN < ERROR < FATAL
# That is loglevel WARN won't log DEBUG and INFO
messages,
# but will log WARN, ERROR, and FATAL messages
#
# Global default log level used for all logging
# entities if not specified
ROOT.LogLevel=DEBUG
#
# The Default Logger instance used within OJB
DEFAULT.LogLevel=DEBUG
# Logger for PersistenceBrokerImpl class
org.apache.ojb.broker.core.PersistenceBrokerImpl.LogLevel=DEBUG
# Logger for PersistenceBrokerFactory class
PersistenceBrokerFactoryDefaultImpl
org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl.LogLevel=DEBUG
# Logger for RepositoryXmlHandler, useful for
debugging parsing of repository.xml!
# persistence capable object metadata
org.apache.ojb.broker.metadata.RepositoryXmlHandler.LogLevel=DEBUG
# Logger for ConnectionDescriptorXmlHandler, useful
for debugging parsing of repository.xml!
# connection specific metadata
org.apache.ojb.broker.metadata.ConnectionDescriptorXmlHandler.LogLevel=DEBUG
# Logger for JdbcAccess, useful for debugging JDBC
related problems
org.apache.ojb.broker.accesslayer.JdbcAccessImpl.LogLevel=DEBUG
# Logger for RsIterator, useful for debugging problems
with Object materialization
org.apache.ojb.broker.accesslayer.RsIterator.LogLevel=DEBUG
# Logger for StatementsForClass, useful for debugging
JDBC Connection related problems
org.apache.ojb.broker.accesslayer.StatementsForClassImpl.LogLevel=DEBUG
# Logger for SqlGenerator, useful for debugging
generation of SQL
org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel=DEBUG
# Logger for RepositoryPersistor
org.apache.ojb.broker.metadata.RepositoryPersistor.LogLevel=DEBUG
# Logger for ConnectionFactory base class
org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.LogLevel=DEBUG
# Logger for ConnectionManager
org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.LogLevel=DEBUG
# Logger for IndirectionHandler class
org.apache.ojb.broker.core.proxy.IndirectionHandler.LogLevel=DEBUG
#
# Special Logger categories used in test suite and
tutorials
#
# Logger for the ODMG Implementation
ODMG.LogLevel=DEBUG
# Logger for the JDO RI Implementation
JDO.LogLevel=DEBUG
# Logger for the performance tests
performance.LogLevel=DEBUG
# Logger for the soda api
soda.LogLevel=DEBUG
# Logger for the factory service
ConfigurableFactory.LogLevel=DEBUG
#
#
#----------------------------------------------------------------------------------------
# End of OJB.properties file
#----------------------------------------------------------------------------------------



	

	
		
____________________________________________________________
Yahoo! Companion - Scarica gratis la toolbar di Ricerca di Yahoo! 
http://companion.yahoo.it

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org

Re: Problems with TM in ejbCreate() --- continued

[Armin Waibel <ar...@apache.org>]

Hi Dino,

sorry forget to reply.
I checked in an attempt to fix your problem in CVS trunk and 1.0_RELEASE 
branch.

http://nagoya.apache.org/eyebrowse/ReadMsg?listName=ojb-dev@db.apache.org&msgNo=8730
or
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=ojb-dev@db.apache.org&msgNo=8731

Replace your files with the modified ones. Hope the made changes will 
fix your problem.

regards,
Armin

Dino Di Cola wrote:

> Armin,
> This problem was driving me crazy... finally I
> rightfully decided to ask for your support again.
> 
> I really Hope to find a solution by tomorrow ;)
> cause I am getting too late with this matter :(
> 
> Thanks in advance!
> 
> d.
> --
> 
>>Hi Dino,
>>
>>I'm working on this, the patch has some unexpected
>>side-effects in 
>>managed environments ;-)
>>Hope to find a solution till tomorrow.
>>
>>regards,
>>Armin
>>
>>Dino Di Cola wrote:
>>
>>>Dear Armin,
>>>
>>>I am testing your patch on
>>>ImplementationJTAImpl#registerOpenDatabase.
>>>The problems regarding the ejbCreate() method
>>>disappeared. Unfortunately I got some problems
>>
>>with
>>
>>>the org.odmg.Database#deletePersistent now.
>>>Again this problem is related to Transaction
>>>Management and was not present with the previous
>>>Oracle9iAS 9.0.2.2 version. 
>>>
>>>The test case I present here is again a simple
>>
>>J2EE
>>
>>>application made up of a test stateless session
>>
>>bean
>>
>>>with a single business method invoked via RMI.
>>>The configuration is the same of the previous
>>
>>e-mail.
>>
>>>What I am trying to do is basically to lookup for
>>
>>an
>>
>>>object (es. SentMail) and deleting it with the
>>>Database#deletePersistent method:
>>>
>>>	/* this is done in ejbCreate()... */
>>>  	org.odmg.Implementation odmg =
>>
>>OJB.getInstance();
>>
>>>	org.odmg.Database db = odmg.newDatabase();
>>>        db.open(DEF_DATABASE_NAME,
>>>Database.OPEN_READ_WRITE);    
>>>	[...]
>>>
>>>	/* this is done in the business method... */
>>>	SentMail objSentMail = (SentMail)
>>>lookupObject(SentMail.class, 4);
>>>  	db.deletePersistent(objSentMail);
>>>
>>>The object is actually found on the DB but when I
>>
>>try
>>
>>>to delete it I got the following exception:
>>>
>>>     [exec] The following exception has been
>>
>>catched:
>>
>>>Transaction was rolled back:
>>>org.odmg.TransactionNotInProgressException: No
>>>transaction in progress, cannot delete persistent;
>>>nested exception is:
>>>     [exec]
>>>com.evermind.server.rmi.OrionRemoteException:
>>>Transaction was rolled back:
>>>org.odmg.TransactionNotInProgressException: No
>>>transaction in progress, cannot delete persistent
>>>     [exec]
>>>org.odmg.TransactionNotInProgressException: No
>>>transaction in progress, cannot delete persistent
>>>     [exec]     at
>>>
>>
> OJB_Tx_StatelessSessionBeanWrapper76.test(OJB_Tx_StatelessSessionBeanWrapper76.java:164)
> 
>>>     [exec]     at
>>>java.lang.reflect.Method.invoke(Native Method)
>>>     [exec]     at
>>>
>>
> com.evermind.server.rmi.RMICallHandler.run(RMICallHandler.java:119)
> 
>>>     [exec]     at
>>>
>>
> com.evermind.server.rmi.RMICallHandler.run(RMICallHandler.java:48)
> 
>>>     [exec]     at
>>>
>>
> EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:804)
> 
>>>     [exec]     at
>>>java.lang.Thread.run(Thread.java:479)
>>>     [exec]     at connection to
>>
>>c-01-091/10.2.20.20
>>
>>>as admin
>>>     [exec]     at
>>>
>>
> com.evermind.server.rmi.RMIConnection.EXCEPTION_ORIGINATES_FROM_THE_REMOTE_SERVER(RMIConnection.java:1576)
> 
>>>     [exec]     at
>>>
>>
> com.evermind.server.rmi.RMIConnection.invokeMethod(RMIConnection.java:1529)
> 
>>>     [exec]     at
>>>
>>
> com.evermind.server.rmi.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:55)
> 
>>>     [exec]     at
>>>
>>
> com.evermind.server.rmi.RecoverableRemoteInvocationHandler.invoke(RecoverableRemoteInvocationHandler.java:22)
> 
>>>     [exec]     at
>>>
>>
> com.evermind.server.ejb.StatelessSessionRemoteInvocationHandler.invoke(StatelessSessionRemoteInvocationHandler.java:50)
> 
>>>     [exec]     at __Proxy5.test(Unknown Source)
>>>     [exec]     at
>>>
>>
> it.enidata.psv.test.ejb.client.TestOJB_Tx.main(TestOJB_Tx.java:45)
> 
>>>     [exec]
>>>     [exec]     Nested exception is:
>>>     [exec]    
>>>org.odmg.TransactionNotInProgressException: No
>>>transaction in progress, cannot delete persistent
>>>     [exec]     at
>>>
>>
> org.apache.ojb.odmg.DatabaseImpl.deletePersistent(Unknown
> 
>>>Source)
>>>     [exec]     at
>>>
>>
> it.enidata.psv.test.ejb.OJB_TxBean.test(OJB_TxBean.java:144)
> 
>>>     [exec]     at
>>>
>>
> OJB_Tx_StatelessSessionBeanWrapper76.test(OJB_Tx_StatelessSessionBeanWrapper76.java:115)
> 
>>>     [exec]     at
>>>java.lang.reflect.Method.invoke(Native Method)
>>>     [exec]     at
>>>
>>
> com.evermind.server.rmi.RMICallHandler.run(RMICallHandler.java:119)
> 
>>>     [exec]     at
>>>
>>
> com.evermind.server.rmi.RMICallHandler.run(RMICallHandler.java:48)
> 
>>>     [exec]     at
>>>
>>
> EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:804)
> 
>>>     [exec]     at
>>>java.lang.Thread.run(Thread.java:479)
>>>     [exec]     at connection to
>>>c-01-091.prirm.pride.it/10.2.20.20
>>>     [exec]     at
>>>
>>
> com.evermind.server.rmi.OrionRemoteException.receive(OrionRemoteException.java:130)
> 
>>>     [exec]     at
>>>
>>
> com.evermind.server.rmi.RMIConnection.handleMethodInvocationResponse(RMIConnection.java:1691)
> 
>>>     [exec]     at
>>>
>>
> com.evermind.server.rmi.RMIConnection.run(RMIConnection.java:532)
> 
>>>     [exec]     at
>>>
>>
> com.evermind.server.rmi.RMIConnection.run(RMIConnection.java:275)
> 
>>>     [exec]     at
>>>
>>
> EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:798)
> 
>>>     [exec]     at
>>>java.lang.Thread.run(Thread.java:484)
>>>
>>>You can find the complete source code for the
>>>OJB_TxBean here below. 
>>>
>>>I am again in your hands... ;) 
>>>Thanks in advance.
>>>
>>>Regards,
>>>
>>>
>>>Dino.
>>>
>>>
>>>ps. (from previous thread...)
>>>
>>>
>>>>>3. I commented out the beginInternTransaction()
>>>>>invocation. Clearly this method is equally
>>
>>invoked
>>
>>>>>following another code flow. Does it mean it was
>>>
>>>called twice before your patch?
>>>
>>>
>>>>this could be the case, but it doesn't matter,
>>>
>>>because 
>>>
>>>
>>>>beginInternTransaction() take care of this.
>>>>
>>>>nearly all operations of the odmg-api have to be
>>
>>in
>>
>>>context of a 
>>>
>>>
>>>>transaction and in managed environments it's not
>>>
>>>allowed to do OJB/ODMG 
>>>
>>>
>>>>related transaction demarcation, thus you always
>>
>>have
>>
>>>to use JTA 
>>>
>>>
>>>>transactions and the easiest way is to use
>>>
>>>container-managed tx.
>>>
>>>
>>>>Alternative you can use bm-tx via UserTransaction.
>>>
>>>--
>>>
>>
> ***********************************************************************
> 
>>>**** Source code for the session bean
>>>*********************************
>>>
>>
> ***********************************************************************
> 
>>>public class OJB_TxBean implements SessionBean {
>>>	
>>>  private SessionContext sessionContext;
>>>  private static final String DEF_DATABASE_NAME =
>>>"dsOJB";
>>>  
>>>  private Implementation odmg;
>>>  private Database db;
>>>  
>>>  public OJB_TxBean() {}
>>>  
>>>  public void ejbActivate() {
>>>  }
>>>  
>>>  public void ejbPassivate() {
>>>  }
>>>  
>>>  public void ejbCreate() throws CreateException {
>>>	  	try {
>>>	  		init();
>>>	  	} catch (InitException e) {
>>>	  		throw new CreateException(e.getMessage());
>>>	  	}  	
>>>  }
>>>
>>>  private void init() throws InitException{
>>>  	/* ---------------------------- */
>>>  	/* Step0 - Getting log4j logger */
>>>  	/* ---------------------------- */
>>>  	Logger logger =
>>>Logger.getLogger("psv.j2ee.testing");
>>>  	logger.debug("OJB_TxBean - init(): begin");
>>>  	 
>>>  	odmg = null;
>>>  	db = null; 	 
>>>  	
>>>  	/* ------------------------------------ */
>>>  	/* Step1 - Initializing ODMG connection */
>>>  	/* ------------------------------------ */
>>>  	 logger.debug("OJB_TxBean - init():
>>
>>initializing
>>
>>>ODMG connection [BEGIN]");
>>>  	 odmg = OJB.getInstance();
>>>
>>>  	 logger.debug("OJB_TxBean - init():
>>>odmg.newDatabase()");
>>>  	 db = odmg.newDatabase();
>>>  	 
>>>  	 try {
>>>  	 	logger.debug("OJB_TxBean - init(): open new
>>>database " + db + " using databaseName name " +
>>>DEF_DATABASE_NAME);
>>>  	 	db.open(DEF_DATABASE_NAME,
>>>Database.OPEN_READ_WRITE);            
>>>  	 } catch (ODMGException e) {
>>>  	 	logger.error("OJB_TxBean - init(): Database
>>
>>open
>>
>>>failed", e);
>>>  	 	throw new InitException(e.getMessage());
>>>  	 } 
>>>  	 
>>>  	 logger.debug("OJB_TxBean - init():
>>
>>initializing
>>
>>>ODMG connection [END]");  
>>>  }
>>>  
>>>  public void ejbRemove() {
>>>  	Logger logger =
>>>Logger.getLogger("psv.j2ee.testing");
>>>  	logger.debug("OJB_TxBean - ejbRemove(): closing
>>>ODMG connection [BEGIN]");
>>>  	try {
>>>  		logger.debug("OJB_TxBean - ejbRemove():
>>>db.close(): " +  db);
>>>  		if (db != null) db.close();
>>>  	} catch (ODMGException e) {
>>>  		logger.error("OJB_TxBean - ejbRemove():
>>
>>closing of
>>
>>>database failed", e);
>>>  	}  	
>>>  	db = null;
>>>  	odmg = null;
>>>  	logger.debug("OJB_TxBean - ejbRemove(): closing
>>>ODMG connection [END]"); 
>>>  }
>>>  
>>>  public void setSessionContext(SessionContext
>>>sessionContext) {
>>>    this.sessionContext = sessionContext;
>>>  }
>>>  
>>>  protected PObject lookupObject(Class target,
>>
>>long
>>
>>>oid) {
>>>  	Logger logger =
>>>Logger.getLogger("psv.j2ee.testing"); 
>>>  	logger.debug("OJB_TxBean - lookupObject():
>>
>>begin");
>>
>>>  	
>>>  	PersistenceBroker broker = null;
>>>  	PObject pObject = null;
>>>
>>>  	try {
>>>  		broker =
>>>
>>
>>PersistenceBrokerFactory.defaultPersistenceBroker();
>>
>>>  		Criteria crit = new Criteria();
>>>  		crit.addEqualTo("oid", new Long(oid));
>>>  		Query query = new QueryByCriteria(target,
>>
>>crit);
>>
>>>  		java.util.Iterator iter =
>>>broker.getCollectionByQuery(query).iterator();
>>>
>>>  		if (iter.hasNext()) pObject = (PObject)
>>>iter.next();
>>>  	} catch (Exception e) {
>>>  		logger.error("OJB_TxBean -  lookupObject():
>>
>>Query
>>
>>>failed", e);
>>>  		throw new EJBException("OJB_TxBean - 
>>>lookupObject(): Query failed", e);
>>>  	} finally {
>>>  		if (broker != null)
>>>  			broker.close();
>>>  	}
>>>  	
>>>  	logger.debug("OJB_TxBean - lookupObject():
>>
>>end");
>>
>>>  	return pObject;
>>>  }
>>>  
>>>  public String test() throws
>>
>>java.rmi.RemoteException
>>
>>>{
>>>  	Logger logger =
>>>Logger.getLogger("psv.j2ee.testing"); 
>>>  	logger.debug("OJB_TxBean - test(): begin");
>>>  	
>>>  	/* ---------------------- */
>>>  	/* --- Business Stuff --- */
>>>  	/* ---------------------- */
>>>  	logger.debug("OJB_TxBean - test(): odmg : " +
>>>odmg);
>>>  	SentMail objSentMail = (SentMail)
>>>lookupObject(SentMail.class, 4);
>>>  	logger.debug("OJB_TxBean - test(): objSentMail
>>
>>: "
>>
>>>+ objSentMail);
>>>  	logger.debug("OJB_TxBean - test():
>>>objSentMail.getSubject() : " +
>>>objSentMail.getSubject());
>>>  	logger.debug("OJB_TxBean - test():
>>>objSentMail.getSend_to() : " +
>>>objSentMail.getSend_to());
>>>  	logger.debug("OJB_TxBean - test():
>>>objSentMail.getRecipient() : " +
>>>objSentMail.getRecipient());
>>>  	
>>>  	logger.debug("OJB_TxBean - test(): objSentMail
>>
>>: "
>>
>>>+ objSentMail);
>>>  	db.deletePersistent(objSentMail);
>>>  	
>>>  	logger.debug("OJB_TxBean - test(): end");
>>>	SimpleDateFormat simpleDateFormat = new
>>>SimpleDateFormat("dd.MM.yyyy hh:mm:ss");
>>>    return "OJB_TxBean - test(): done [" + 
>>>
>>
> simpleDateFormat.format(Calendar.getInstance().getTime())
> 
>>>+ "]";
>>>  }
>>>  
>>>}
>>>--
>>>
>>>
>>>
>>>
>>>
>>> --- Armin Waibel <ar...@apache.org> ha scritto: 
>>>
>>>
>>>>Hi Dino,
>>>>
>>>>Dino Di Cola wrote:
>>>>
>>>>
>>>>
>>>>>Dear Armin,
>>>>>first of all thanks for your prompt reply!
>>>>>
>>>>>I applied the change to the
>>>>>ImplementationJTAImpl#registerOpenDatabase and
>>>>>executed the test from scratch. 
>>>>>My simple test application works fine now.
>>>>>I deployed also the main J2EE application and
>>>>
>>>>works
>>>>
>>>>
>>>>>also there at first sight.
>>>>>
>>>>>I would like to have more insight from you
>>>>
>>>>regarding
>>>>
>>>>
>>>>>the patch you proposed to apply in
>>>>>ImplementationJTAImpl class.
>>>>>
>>>>>1. You wrote the following: "OJB always lookup a
>>>>>running JTA-transaction this can't be successful
>>>>
>>>>when
>>>>
>>>>
>>>>>db.open(...) is called on ejbCreate()".
>>>>>  Could you please give me more info? I cannot
>>>>
>>>>see
>>>>
>>>>
>>>>>the problem with ejbCreate(). Thanks!
>>>>>
>>>>
>>>>ejbCreate() was called on session bean
>>>>initialization, this could be 
>>>>done e.g. at startup of your appServer to setup a
>>>>pool of session bean 
>>>>instances. Thus there is no guarantee that the
>>>>session bean was created 
>>>>in context of a running tx.
>>>>
>>>>
>>>>
>>>>
>>>>>2. You wrote me it could be a "bug" in odmg
>>>>>implementation. And clearly you seems right. 
>>>>
>>>>I will fix this in CVS ASAP.
>>>>
>>>>
>>>>
>>>>
>>>>>  I cannot understand however why it was
>>>>
>>>>successfully
>>>>
>>>>
>>>>>running on previous versions of ora9ias!?!
>>>>>
>>>>
>>>>e.g. in your previous version your appServer
>>
>>doesn't
>>
>>>>setup a session 
>>>>bean pool at startup, so the instances were
>>
>>created
>>
>>>>when needed and thus 
>>>>when a tx was reachable --> no exception
>>>>
>>>>
>>>>
>>>>
>>>>>3. I commented out the beginInternTransaction()
>>>>>invocation. Clearly this method is equally
>>
>>invoked
>>
>>>>>following another code flow. 
>>>>>  Does it mean it was called twice before your
>>>>
>>>>patch?
>>>>
>>>>this could be the case, but it doesn't matter,
>>>>because 
>>>>beginInternTransaction() take care of this.
>>>>
>>>>
>>>>
>>>>
>>>>>4. My Session Bean is substantially very close to
>>>>>
>>>>
>>>src\ejb\org\apache\ojb\ejb\odmg\ODMGSessionBean.java
>>>
>>>>>(taken from the db-ojb-1.0.rc7 distribution).
>>>>>  The only difference I note is on the
>>
>>"Required"
>>
>>>>>attribute marked in the ODMGSessionBean.java
>>>>
>>>>javadoc.
>>>>
>>>>
>>>>>I use "NotSupported" instead. 
>>>>>  Have I to change the attribute to "Required"? 
>>
>>>>
>>>>
>>>>nearly all operations of the odmg-api have to be
>>
>>in
>>
>>>>context of an 
>>>>transaction and in managed environments it's not
>>>>allowed to do OJB/ODMG 
>>>>related transaction demarcation, thus you always
>>>>have to use JTA 
>>>>transactions and the easiest way is to use
>>>>container-managed tx.
>>>>Alternative you can use bm-tx via UserTransaction.
>>>>I wonder how you could use odmg-api in managed
>>>>environment with 
>>>>transaction attribute "NotSupported"?
>>>>
>>>>
>>>>
>>>>
>>>>>5. I am quite sure about this bug (anyway I will
>>>>
>>>>check
>>>>
>>>>
>>>>>it more and more and I will keep you informed). 
>>>>>  If you are certain of this bug too, in what
>>>>
>>>>release
>>>>
>>>>
>>>>>do you think to fix it? 
>>>>
>>>>Think the next upcoming OJB 1.0.1 will contain
>>
>>this
>>
>>>>fix.
>>>>
>>>>
>>>>
>>>>
>>>>>  Have you planned a target release date for
>>
>>next
>>
>>>>OJB
>>>>
>>>>
>>>>>release?
>>>>
>>>>We planed a maintenance release 1.0.1 for last
>>
>>week
>>
>>>>;-)
>>>>I'm sure we will release the new version in near
>>>>future.
>>>>
>>>>
>>>>
>>>>
>>>>>  What can I do in the meantime a new release
>>>>
>>>>will be
>>>>
>>>>
>>>>>officially distributed? 
>>>>>
>>>>
>>>>use the patched class
>>>>
>>>>
>>>>
>>>>
>>>>>Armin, I really appreciated your help.
>>>>>Hope you will answer to all my questions without
>>>>>getting bored :)
>>>>>
>>>>
>>>>In return for services, never run down OJB ;-)
>>>>
>>>>regards,
>>>>Armin
>>>>
>>>>
>>>>
>>>>
>>>>>Thanks, 
>>>>>
>>>>>d.
>>>>>--
>>>>>
>>>>>
>>>>>
>>>>>	
>>>>>
>>>>>	
>>>>>		
>>>>>
>>>>
> ____________________________________________________________
> 
>>>>>Yahoo! Companion - Scarica gratis la toolbar di
>>>>
>>>>Ricerca di Yahoo! 
>>>>
>>>>
>>>>>http://companion.yahoo.it
>>>>>
>>>>>
>>>>
> ---------------------------------------------------------------------
> 
>>>>>To unsubscribe, e-mail:
>>>>
>>>>ojb-user-unsubscribe@db.apache.org
>>>>
>>>>
>>>>>For additional commands, e-mail:
>>>>
>>>>ojb-user-help@db.apache.org
>>>>
>>>>
>>>>>
> ---------------------------------------------------------------------
> 
>>>>To unsubscribe, e-mail:
>>>>ojb-user-unsubscribe@db.apache.org
>>>>For additional commands, e-mail:
>>>>ojb-user-help@db.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>>	
>>>
>>>	
>>>		
>>>
>>
> ____________________________________________________________
> 
>>>Yahoo! Companion - Scarica gratis la toolbar di
>>
>>Ricerca di Yahoo! 
>>
>>>http://companion.yahoo.it
>>>
>>>
>>
> ---------------------------------------------------------------------
> 
>>>To unsubscribe, e-mail:
>>
>>ojb-user-unsubscribe@db.apache.org
>>
>>>For additional commands, e-mail:
>>
>>ojb-user-help@db.apache.org
>>
>>>
>>>
>>
> ---------------------------------------------------------------------
> 
>>To unsubscribe, e-mail:
>>ojb-user-unsubscribe@db.apache.org
>>For additional commands, e-mail:
>>ojb-user-help@db.apache.org
>>
>> 
> 
> 
> 
> 	
> 
> 	
> 		
> ____________________________________________________________
> Yahoo! Companion - Scarica gratis la toolbar di Ricerca di Yahoo! 
> http://companion.yahoo.it
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
> 
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org

Re: Problems with TM in ejbCreate() --- continued

[Dino Di Cola <di...@yahoo.it>]

Armin,
This problem was driving me crazy... finally I
rightfully decided to ask for your support again.

I really Hope to find a solution by tomorrow ;)
cause I am getting too late with this matter :(

Thanks in advance!

d.
--
> Hi Dino,
> 
> I'm working on this, the patch has some unexpected
> side-effects in 
> managed environments ;-)
> Hope to find a solution till tomorrow.
> 
> regards,
> Armin
> 
> Dino Di Cola wrote:
> > Dear Armin,
> > 
> > I am testing your patch on
> > ImplementationJTAImpl#registerOpenDatabase.
> > The problems regarding the ejbCreate() method
> > disappeared. Unfortunately I got some problems
> with
> > the org.odmg.Database#deletePersistent now.
> > Again this problem is related to Transaction
> > Management and was not present with the previous
> > Oracle9iAS 9.0.2.2 version. 
> > 
> > The test case I present here is again a simple
> J2EE
> > application made up of a test stateless session
> bean
> > with a single business method invoked via RMI.
> > The configuration is the same of the previous
> e-mail.
> > What I am trying to do is basically to lookup for
> an
> > object (es. SentMail) and deleting it with the
> > Database#deletePersistent method:
> > 
> > 	/* this is done in ejbCreate()... */
> >   	org.odmg.Implementation odmg =
> OJB.getInstance();
> > 	org.odmg.Database db = odmg.newDatabase();
> >         db.open(DEF_DATABASE_NAME,
> > Database.OPEN_READ_WRITE);    
> > 	[...]
> > 
> > 	/* this is done in the business method... */
> > 	SentMail objSentMail = (SentMail)
> > lookupObject(SentMail.class, 4);
> >   	db.deletePersistent(objSentMail);
> > 
> > The object is actually found on the DB but when I
> try
> > to delete it I got the following exception:
> > 
> >      [exec] The following exception has been
> catched:
> > Transaction was rolled back:
> > org.odmg.TransactionNotInProgressException: No
> > transaction in progress, cannot delete persistent;
> > nested exception is:
> >      [exec]
> > com.evermind.server.rmi.OrionRemoteException:
> > Transaction was rolled back:
> > org.odmg.TransactionNotInProgressException: No
> > transaction in progress, cannot delete persistent
> >      [exec]
> > org.odmg.TransactionNotInProgressException: No
> > transaction in progress, cannot delete persistent
> >      [exec]     at
> >
>
OJB_Tx_StatelessSessionBeanWrapper76.test(OJB_Tx_StatelessSessionBeanWrapper76.java:164)
> >      [exec]     at
> > java.lang.reflect.Method.invoke(Native Method)
> >      [exec]     at
> >
>
com.evermind.server.rmi.RMICallHandler.run(RMICallHandler.java:119)
> >      [exec]     at
> >
>
com.evermind.server.rmi.RMICallHandler.run(RMICallHandler.java:48)
> >      [exec]     at
> >
>
EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:804)
> >      [exec]     at
> > java.lang.Thread.run(Thread.java:479)
> >      [exec]     at connection to
> c-01-091/10.2.20.20
> > as admin
> >      [exec]     at
> >
>
com.evermind.server.rmi.RMIConnection.EXCEPTION_ORIGINATES_FROM_THE_REMOTE_SERVER(RMIConnection.java:1576)
> >      [exec]     at
> >
>
com.evermind.server.rmi.RMIConnection.invokeMethod(RMIConnection.java:1529)
> >      [exec]     at
> >
>
com.evermind.server.rmi.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:55)
> >      [exec]     at
> >
>
com.evermind.server.rmi.RecoverableRemoteInvocationHandler.invoke(RecoverableRemoteInvocationHandler.java:22)
> >      [exec]     at
> >
>
com.evermind.server.ejb.StatelessSessionRemoteInvocationHandler.invoke(StatelessSessionRemoteInvocationHandler.java:50)
> >      [exec]     at __Proxy5.test(Unknown Source)
> >      [exec]     at
> >
>
it.enidata.psv.test.ejb.client.TestOJB_Tx.main(TestOJB_Tx.java:45)
> >      [exec]
> >      [exec]     Nested exception is:
> >      [exec]    
> > org.odmg.TransactionNotInProgressException: No
> > transaction in progress, cannot delete persistent
> >      [exec]     at
> >
>
org.apache.ojb.odmg.DatabaseImpl.deletePersistent(Unknown
> > Source)
> >      [exec]     at
> >
>
it.enidata.psv.test.ejb.OJB_TxBean.test(OJB_TxBean.java:144)
> >      [exec]     at
> >
>
OJB_Tx_StatelessSessionBeanWrapper76.test(OJB_Tx_StatelessSessionBeanWrapper76.java:115)
> >      [exec]     at
> > java.lang.reflect.Method.invoke(Native Method)
> >      [exec]     at
> >
>
com.evermind.server.rmi.RMICallHandler.run(RMICallHandler.java:119)
> >      [exec]     at
> >
>
com.evermind.server.rmi.RMICallHandler.run(RMICallHandler.java:48)
> >      [exec]     at
> >
>
EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:804)
> >      [exec]     at
> > java.lang.Thread.run(Thread.java:479)
> >      [exec]     at connection to
> > c-01-091.prirm.pride.it/10.2.20.20
> >      [exec]     at
> >
>
com.evermind.server.rmi.OrionRemoteException.receive(OrionRemoteException.java:130)
> >      [exec]     at
> >
>
com.evermind.server.rmi.RMIConnection.handleMethodInvocationResponse(RMIConnection.java:1691)
> >      [exec]     at
> >
>
com.evermind.server.rmi.RMIConnection.run(RMIConnection.java:532)
> >      [exec]     at
> >
>
com.evermind.server.rmi.RMIConnection.run(RMIConnection.java:275)
> >      [exec]     at
> >
>
EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:798)
> >      [exec]     at
> > java.lang.Thread.run(Thread.java:484)
> > 
> > You can find the complete source code for the
> > OJB_TxBean here below. 
> > 
> > I am again in your hands... ;) 
> > Thanks in advance.
> > 
> > Regards,
> > 
> > 
> > Dino.
> > 
> > 
> > ps. (from previous thread...)
> > 
> >>>3. I commented out the beginInternTransaction()
> >>>invocation. Clearly this method is equally
> invoked
> >>>following another code flow. Does it mean it was
> > 
> > called twice before your patch?
> > 
> >>this could be the case, but it doesn't matter,
> > 
> > because 
> > 
> >>beginInternTransaction() take care of this.
> >>
> >>nearly all operations of the odmg-api have to be
> in
> > 
> > context of a 
> > 
> >>transaction and in managed environments it's not
> > 
> > allowed to do OJB/ODMG 
> > 
> >>related transaction demarcation, thus you always
> have
> > 
> > to use JTA 
> > 
> >>transactions and the easiest way is to use
> > 
> > container-managed tx.
> > 
> >>Alternative you can use bm-tx via UserTransaction.
> > 
> > --
> >
>
***********************************************************************
> > **** Source code for the session bean
> > *********************************
> >
>
***********************************************************************
> > public class OJB_TxBean implements SessionBean {
> > 	
> >   private SessionContext sessionContext;
> >   private static final String DEF_DATABASE_NAME =
> > "dsOJB";
> >   
> >   private Implementation odmg;
> >   private Database db;
> >   
> >   public OJB_TxBean() {}
> >   
> >   public void ejbActivate() {
> >   }
> >   
> >   public void ejbPassivate() {
> >   }
> >   
> >   public void ejbCreate() throws CreateException {
> > 	  	try {
> > 	  		init();
> > 	  	} catch (InitException e) {
> > 	  		throw new CreateException(e.getMessage());
> > 	  	}  	
> >   }
> > 
> >   private void init() throws InitException{
> >   	/* ---------------------------- */
> >   	/* Step0 - Getting log4j logger */
> >   	/* ---------------------------- */
> >   	Logger logger =
> > Logger.getLogger("psv.j2ee.testing");
> >   	logger.debug("OJB_TxBean - init(): begin");
> >   	 
> >   	odmg = null;
> >   	db = null; 	 
> >   	
> >   	/* ------------------------------------ */
> >   	/* Step1 - Initializing ODMG connection */
> >   	/* ------------------------------------ */
> >   	 logger.debug("OJB_TxBean - init():
> initializing
> > ODMG connection [BEGIN]");
> >   	 odmg = OJB.getInstance();
> > 
> >   	 logger.debug("OJB_TxBean - init():
> > odmg.newDatabase()");
> >   	 db = odmg.newDatabase();
> >   	 
> >   	 try {
> >   	 	logger.debug("OJB_TxBean - init(): open new
> > database " + db + " using databaseName name " +
> > DEF_DATABASE_NAME);
> >   	 	db.open(DEF_DATABASE_NAME,
> > Database.OPEN_READ_WRITE);            
> >   	 } catch (ODMGException e) {
> >   	 	logger.error("OJB_TxBean - init(): Database
> open
> > failed", e);
> >   	 	throw new InitException(e.getMessage());
> >   	 } 
> >   	 
> >   	 logger.debug("OJB_TxBean - init():
> initializing
> > ODMG connection [END]");  
> >   }
> >   
> >   public void ejbRemove() {
> >   	Logger logger =
> > Logger.getLogger("psv.j2ee.testing");
> >   	logger.debug("OJB_TxBean - ejbRemove(): closing
> > ODMG connection [BEGIN]");
> >   	try {
> >   		logger.debug("OJB_TxBean - ejbRemove():
> > db.close(): " +  db);
> >   		if (db != null) db.close();
> >   	} catch (ODMGException e) {
> >   		logger.error("OJB_TxBean - ejbRemove():
> closing of
> > database failed", e);
> >   	}  	
> >   	db = null;
> >   	odmg = null;
> >   	logger.debug("OJB_TxBean - ejbRemove(): closing
> > ODMG connection [END]"); 
> >   }
> >   
> >   public void setSessionContext(SessionContext
> > sessionContext) {
> >     this.sessionContext = sessionContext;
> >   }
> >   
> >   protected PObject lookupObject(Class target,
> long
> > oid) {
> >   	Logger logger =
> > Logger.getLogger("psv.j2ee.testing"); 
> >   	logger.debug("OJB_TxBean - lookupObject():
> begin");
> >   	
> >   	PersistenceBroker broker = null;
> >   	PObject pObject = null;
> > 
> >   	try {
> >   		broker =
> >
> PersistenceBrokerFactory.defaultPersistenceBroker();
> > 
> >   		Criteria crit = new Criteria();
> >   		crit.addEqualTo("oid", new Long(oid));
> >   		Query query = new QueryByCriteria(target,
> crit);
> > 
> >   		java.util.Iterator iter =
> > broker.getCollectionByQuery(query).iterator();
> > 
> >   		if (iter.hasNext()) pObject = (PObject)
> > iter.next();
> >   	} catch (Exception e) {
> >   		logger.error("OJB_TxBean -  lookupObject():
> Query
> > failed", e);
> >   		throw new EJBException("OJB_TxBean - 
> > lookupObject(): Query failed", e);
> >   	} finally {
> >   		if (broker != null)
> >   			broker.close();
> >   	}
> >   	
> >   	logger.debug("OJB_TxBean - lookupObject():
> end");
> >   	return pObject;
> >   }
> >   
> >   public String test() throws
> java.rmi.RemoteException
> > {
> >   	Logger logger =
> > Logger.getLogger("psv.j2ee.testing"); 
> >   	logger.debug("OJB_TxBean - test(): begin");
> >   	
> >   	/* ---------------------- */
> >   	/* --- Business Stuff --- */
> >   	/* ---------------------- */
> >   	logger.debug("OJB_TxBean - test(): odmg : " +
> > odmg);
> >   	SentMail objSentMail = (SentMail)
> > lookupObject(SentMail.class, 4);
> >   	logger.debug("OJB_TxBean - test(): objSentMail
> : "
> > + objSentMail);
> >   	logger.debug("OJB_TxBean - test():
> > objSentMail.getSubject() : " +
> > objSentMail.getSubject());
> >   	logger.debug("OJB_TxBean - test():
> > objSentMail.getSend_to() : " +
> > objSentMail.getSend_to());
> >   	logger.debug("OJB_TxBean - test():
> > objSentMail.getRecipient() : " +
> > objSentMail.getRecipient());
> >   	
> >   	logger.debug("OJB_TxBean - test(): objSentMail
> : "
> > + objSentMail);
> >   	db.deletePersistent(objSentMail);
> >   	
> >   	logger.debug("OJB_TxBean - test(): end");
> > 	SimpleDateFormat simpleDateFormat = new
> > SimpleDateFormat("dd.MM.yyyy hh:mm:ss");
> >     return "OJB_TxBean - test(): done [" + 
> >
>
simpleDateFormat.format(Calendar.getInstance().getTime())
> > + "]";
> >   }
> >   
> > }
> > --
> > 
> > 
> > 
> > 
> > 
> >  --- Armin Waibel <ar...@apache.org> ha scritto: 
> > 
> >>Hi Dino,
> >>
> >>Dino Di Cola wrote:
> >>
> >>
> >>>Dear Armin,
> >>>first of all thanks for your prompt reply!
> >>>
> >>>I applied the change to the
> >>>ImplementationJTAImpl#registerOpenDatabase and
> >>>executed the test from scratch. 
> >>>My simple test application works fine now.
> >>>I deployed also the main J2EE application and
> >>
> >>works
> >>
> >>>also there at first sight.
> >>>
> >>>I would like to have more insight from you
> >>
> >>regarding
> >>
> >>>the patch you proposed to apply in
> >>>ImplementationJTAImpl class.
> >>>
> >>>1. You wrote the following: "OJB always lookup a
> >>>running JTA-transaction this can't be successful
> >>
> >>when
> >>
> >>>db.open(...) is called on ejbCreate()".
> >>>   Could you please give me more info? I cannot
> >>
> >>see
> >>
> >>>the problem with ejbCreate(). Thanks!
> >>>
> >>
> >>ejbCreate() was called on session bean
> >>initialization, this could be 
> >>done e.g. at startup of your appServer to setup a
> >>pool of session bean 
> >>instances. Thus there is no guarantee that the
> >>session bean was created 
> >>in context of a running tx.
> >>
> >>
> >>
> >>>2. You wrote me it could be a "bug" in odmg
> >>>implementation. And clearly you seems right. 
> >>
> >>I will fix this in CVS ASAP.
> >>
> >>
> >>
> >>>   I cannot understand however why it was
> >>
> >>successfully
> >>
> >>>running on previous versions of ora9ias!?!
> >>>
> >>
> >>e.g. in your previous version your appServer
> doesn't
> >>setup a session 
> >>bean pool at startup, so the instances were
> created
> >>when needed and thus 
> >>when a tx was reachable --> no exception
> >>
> >>
> >>
> >>>3. I commented out the beginInternTransaction()
> >>>invocation. Clearly this method is equally
> invoked
> >>>following another code flow. 
> >>>   Does it mean it was called twice before your
> >>
> >>patch?
> >>
> >>this could be the case, but it doesn't matter,
> >>because 
> >>beginInternTransaction() take care of this.
> >>
> >>
> >>
> >>>4. My Session Bean is substantially very close to
> >>>
> >>
>
>>src\ejb\org\apache\ojb\ejb\odmg\ODMGSessionBean.java
> >>
> >>>(taken from the db-ojb-1.0.rc7 distribution).
> >>>   The only difference I note is on the
> "Required"
> >>>attribute marked in the ODMGSessionBean.java
> >>
> >>javadoc.
> >>
> >>>I use "NotSupported" instead. 
> >>>   Have I to change the attribute to "Required"? 
> 
> >>
> >> 
> >>
> >>nearly all operations of the odmg-api have to be
> in
> >>context of an 
> >>transaction and in managed environments it's not
> >>allowed to do OJB/ODMG 
> >>related transaction demarcation, thus you always
> >>have to use JTA 
> >>transactions and the easiest way is to use
> >>container-managed tx.
> >>Alternative you can use bm-tx via UserTransaction.
> >>I wonder how you could use odmg-api in managed
> >>environment with 
> >>transaction attribute "NotSupported"?
> >>
> >>
> >>
> >>>5. I am quite sure about this bug (anyway I will
> >>
> >>check
> >>
> >>>it more and more and I will keep you informed). 
> >>>   If you are certain of this bug too, in what
> >>
> >>release
> >>
> >>>do you think to fix it? 
> >>
> >>Think the next upcoming OJB 1.0.1 will contain
> this
> >>fix.
> >>
> >>
> >>
> >>>   Have you planned a target release date for
> next
> >>
> >>OJB
> >>
> >>>release?
> >>
> >>We planed a maintenance release 1.0.1 for last
> week
> >>;-)
> >>I'm sure we will release the new version in near
> >>future.
> >>
> >>
> >>
> >>>   What can I do in the meantime a new release
> >>
> >>will be
> >>
> >>>officially distributed? 
> >>>
> >>
> >>use the patched class
> >>
> >>
> >>
> >>>Armin, I really appreciated your help.
> >>>Hope you will answer to all my questions without
> >>>getting bored :)
> >>>
> >>
> >>In return for services, never run down OJB ;-)
> >>
> >>regards,
> >>Armin
> >>
> >>
> >>
> >>>Thanks, 
> >>>
> >>>d.
> >>>--
> >>>
> >>>
> >>>
> >>>	
> >>>
> >>>	
> >>>		
> >>>
> >>
> >
>
____________________________________________________________
> > 
> >>>Yahoo! Companion - Scarica gratis la toolbar di
> >>
> >>Ricerca di Yahoo! 
> >>
> >>>http://companion.yahoo.it
> >>>
> >>>
> >>
> >
>
---------------------------------------------------------------------
> > 
> >>>To unsubscribe, e-mail:
> >>
> >>ojb-user-unsubscribe@db.apache.org
> >>
> >>>For additional commands, e-mail:
> >>
> >>ojb-user-help@db.apache.org
> >>
> >>>
> >>>
> >>
> >
>
---------------------------------------------------------------------
> > 
> >>To unsubscribe, e-mail:
> >>ojb-user-unsubscribe@db.apache.org
> >>For additional commands, e-mail:
> >>ojb-user-help@db.apache.org
> >>
> >> 
> > 
> > 
> > 
> > 	
> > 
> > 	
> > 		
> >
>
____________________________________________________________
> > Yahoo! Companion - Scarica gratis la toolbar di
> Ricerca di Yahoo! 
> > http://companion.yahoo.it
> > 
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> ojb-user-unsubscribe@db.apache.org
> > For additional commands, e-mail:
> ojb-user-help@db.apache.org
> > 
> > 
> > 
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail:
> ojb-user-help@db.apache.org
> 
>  


	

	
		
____________________________________________________________
Yahoo! Companion - Scarica gratis la toolbar di Ricerca di Yahoo! 
http://companion.yahoo.it

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org

Re: Problems with TM in ejbCreate() --- continued

[Armin Waibel <ar...@apache.org>]

Hi Dino,

I'm working on this, the patch has some unexpected side-effects in 
managed environments ;-)
Hope to find a solution till tomorrow.

regards,
Armin

Dino Di Cola wrote:
> Dear Armin,
> 
> I am testing your patch on
> ImplementationJTAImpl#registerOpenDatabase.
> The problems regarding the ejbCreate() method
> disappeared. Unfortunately I got some problems with
> the org.odmg.Database#deletePersistent now.
> Again this problem is related to Transaction
> Management and was not present with the previous
> Oracle9iAS 9.0.2.2 version. 
> 
> The test case I present here is again a simple J2EE
> application made up of a test stateless session bean
> with a single business method invoked via RMI.
> The configuration is the same of the previous e-mail.
> What I am trying to do is basically to lookup for an
> object (es. SentMail) and deleting it with the
> Database#deletePersistent method:
> 
> 	/* this is done in ejbCreate()... */
>   	org.odmg.Implementation odmg = OJB.getInstance();
> 	org.odmg.Database db = odmg.newDatabase();
>         db.open(DEF_DATABASE_NAME,
> Database.OPEN_READ_WRITE);    
> 	[...]
> 
> 	/* this is done in the business method... */
> 	SentMail objSentMail = (SentMail)
> lookupObject(SentMail.class, 4);
>   	db.deletePersistent(objSentMail);
> 
> The object is actually found on the DB but when I try
> to delete it I got the following exception:
> 
>      [exec] The following exception has been catched:
> Transaction was rolled back:
> org.odmg.TransactionNotInProgressException: No
> transaction in progress, cannot delete persistent;
> nested exception is:
>      [exec]
> com.evermind.server.rmi.OrionRemoteException:
> Transaction was rolled back:
> org.odmg.TransactionNotInProgressException: No
> transaction in progress, cannot delete persistent
>      [exec]
> org.odmg.TransactionNotInProgressException: No
> transaction in progress, cannot delete persistent
>      [exec]     at
> OJB_Tx_StatelessSessionBeanWrapper76.test(OJB_Tx_StatelessSessionBeanWrapper76.java:164)
>      [exec]     at
> java.lang.reflect.Method.invoke(Native Method)
>      [exec]     at
> com.evermind.server.rmi.RMICallHandler.run(RMICallHandler.java:119)
>      [exec]     at
> com.evermind.server.rmi.RMICallHandler.run(RMICallHandler.java:48)
>      [exec]     at
> EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:804)
>      [exec]     at
> java.lang.Thread.run(Thread.java:479)
>      [exec]     at connection to c-01-091/10.2.20.20
> as admin
>      [exec]     at
> com.evermind.server.rmi.RMIConnection.EXCEPTION_ORIGINATES_FROM_THE_REMOTE_SERVER(RMIConnection.java:1576)
>      [exec]     at
> com.evermind.server.rmi.RMIConnection.invokeMethod(RMIConnection.java:1529)
>      [exec]     at
> com.evermind.server.rmi.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:55)
>      [exec]     at
> com.evermind.server.rmi.RecoverableRemoteInvocationHandler.invoke(RecoverableRemoteInvocationHandler.java:22)
>      [exec]     at
> com.evermind.server.ejb.StatelessSessionRemoteInvocationHandler.invoke(StatelessSessionRemoteInvocationHandler.java:50)
>      [exec]     at __Proxy5.test(Unknown Source)
>      [exec]     at
> it.enidata.psv.test.ejb.client.TestOJB_Tx.main(TestOJB_Tx.java:45)
>      [exec]
>      [exec]     Nested exception is:
>      [exec]    
> org.odmg.TransactionNotInProgressException: No
> transaction in progress, cannot delete persistent
>      [exec]     at
> org.apache.ojb.odmg.DatabaseImpl.deletePersistent(Unknown
> Source)
>      [exec]     at
> it.enidata.psv.test.ejb.OJB_TxBean.test(OJB_TxBean.java:144)
>      [exec]     at
> OJB_Tx_StatelessSessionBeanWrapper76.test(OJB_Tx_StatelessSessionBeanWrapper76.java:115)
>      [exec]     at
> java.lang.reflect.Method.invoke(Native Method)
>      [exec]     at
> com.evermind.server.rmi.RMICallHandler.run(RMICallHandler.java:119)
>      [exec]     at
> com.evermind.server.rmi.RMICallHandler.run(RMICallHandler.java:48)
>      [exec]     at
> EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:804)
>      [exec]     at
> java.lang.Thread.run(Thread.java:479)
>      [exec]     at connection to
> c-01-091.prirm.pride.it/10.2.20.20
>      [exec]     at
> com.evermind.server.rmi.OrionRemoteException.receive(OrionRemoteException.java:130)
>      [exec]     at
> com.evermind.server.rmi.RMIConnection.handleMethodInvocationResponse(RMIConnection.java:1691)
>      [exec]     at
> com.evermind.server.rmi.RMIConnection.run(RMIConnection.java:532)
>      [exec]     at
> com.evermind.server.rmi.RMIConnection.run(RMIConnection.java:275)
>      [exec]     at
> EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:798)
>      [exec]     at
> java.lang.Thread.run(Thread.java:484)
> 
> You can find the complete source code for the
> OJB_TxBean here below. 
> 
> I am again in your hands... ;) 
> Thanks in advance.
> 
> Regards,
> 
> 
> Dino.
> 
> 
> ps. (from previous thread...)
> 
>>>3. I commented out the beginInternTransaction()
>>>invocation. Clearly this method is equally invoked
>>>following another code flow. Does it mean it was
> 
> called twice before your patch?
> 
>>this could be the case, but it doesn't matter,
> 
> because 
> 
>>beginInternTransaction() take care of this.
>>
>>nearly all operations of the odmg-api have to be in
> 
> context of a 
> 
>>transaction and in managed environments it's not
> 
> allowed to do OJB/ODMG 
> 
>>related transaction demarcation, thus you always have
> 
> to use JTA 
> 
>>transactions and the easiest way is to use
> 
> container-managed tx.
> 
>>Alternative you can use bm-tx via UserTransaction.
> 
> --
> ***********************************************************************
> **** Source code for the session bean
> *********************************
> ***********************************************************************
> public class OJB_TxBean implements SessionBean {
> 	
>   private SessionContext sessionContext;
>   private static final String DEF_DATABASE_NAME =
> "dsOJB";
>   
>   private Implementation odmg;
>   private Database db;
>   
>   public OJB_TxBean() {}
>   
>   public void ejbActivate() {
>   }
>   
>   public void ejbPassivate() {
>   }
>   
>   public void ejbCreate() throws CreateException {
> 	  	try {
> 	  		init();
> 	  	} catch (InitException e) {
> 	  		throw new CreateException(e.getMessage());
> 	  	}  	
>   }
> 
>   private void init() throws InitException{
>   	/* ---------------------------- */
>   	/* Step0 - Getting log4j logger */
>   	/* ---------------------------- */
>   	Logger logger =
> Logger.getLogger("psv.j2ee.testing");
>   	logger.debug("OJB_TxBean - init(): begin");
>   	 
>   	odmg = null;
>   	db = null; 	 
>   	
>   	/* ------------------------------------ */
>   	/* Step1 - Initializing ODMG connection */
>   	/* ------------------------------------ */
>   	 logger.debug("OJB_TxBean - init(): initializing
> ODMG connection [BEGIN]");
>   	 odmg = OJB.getInstance();
> 
>   	 logger.debug("OJB_TxBean - init():
> odmg.newDatabase()");
>   	 db = odmg.newDatabase();
>   	 
>   	 try {
>   	 	logger.debug("OJB_TxBean - init(): open new
> database " + db + " using databaseName name " +
> DEF_DATABASE_NAME);
>   	 	db.open(DEF_DATABASE_NAME,
> Database.OPEN_READ_WRITE);            
>   	 } catch (ODMGException e) {
>   	 	logger.error("OJB_TxBean - init(): Database open
> failed", e);
>   	 	throw new InitException(e.getMessage());
>   	 } 
>   	 
>   	 logger.debug("OJB_TxBean - init(): initializing
> ODMG connection [END]");  
>   }
>   
>   public void ejbRemove() {
>   	Logger logger =
> Logger.getLogger("psv.j2ee.testing");
>   	logger.debug("OJB_TxBean - ejbRemove(): closing
> ODMG connection [BEGIN]");
>   	try {
>   		logger.debug("OJB_TxBean - ejbRemove():
> db.close(): " +  db);
>   		if (db != null) db.close();
>   	} catch (ODMGException e) {
>   		logger.error("OJB_TxBean - ejbRemove(): closing of
> database failed", e);
>   	}  	
>   	db = null;
>   	odmg = null;
>   	logger.debug("OJB_TxBean - ejbRemove(): closing
> ODMG connection [END]"); 
>   }
>   
>   public void setSessionContext(SessionContext
> sessionContext) {
>     this.sessionContext = sessionContext;
>   }
>   
>   protected PObject lookupObject(Class target, long
> oid) {
>   	Logger logger =
> Logger.getLogger("psv.j2ee.testing"); 
>   	logger.debug("OJB_TxBean - lookupObject(): begin");
>   	
>   	PersistenceBroker broker = null;
>   	PObject pObject = null;
> 
>   	try {
>   		broker =
> PersistenceBrokerFactory.defaultPersistenceBroker();
> 
>   		Criteria crit = new Criteria();
>   		crit.addEqualTo("oid", new Long(oid));
>   		Query query = new QueryByCriteria(target, crit);
> 
>   		java.util.Iterator iter =
> broker.getCollectionByQuery(query).iterator();
> 
>   		if (iter.hasNext()) pObject = (PObject)
> iter.next();
>   	} catch (Exception e) {
>   		logger.error("OJB_TxBean -  lookupObject(): Query
> failed", e);
>   		throw new EJBException("OJB_TxBean - 
> lookupObject(): Query failed", e);
>   	} finally {
>   		if (broker != null)
>   			broker.close();
>   	}
>   	
>   	logger.debug("OJB_TxBean - lookupObject(): end");
>   	return pObject;
>   }
>   
>   public String test() throws java.rmi.RemoteException
> {
>   	Logger logger =
> Logger.getLogger("psv.j2ee.testing"); 
>   	logger.debug("OJB_TxBean - test(): begin");
>   	
>   	/* ---------------------- */
>   	/* --- Business Stuff --- */
>   	/* ---------------------- */
>   	logger.debug("OJB_TxBean - test(): odmg : " +
> odmg);
>   	SentMail objSentMail = (SentMail)
> lookupObject(SentMail.class, 4);
>   	logger.debug("OJB_TxBean - test(): objSentMail : "
> + objSentMail);
>   	logger.debug("OJB_TxBean - test():
> objSentMail.getSubject() : " +
> objSentMail.getSubject());
>   	logger.debug("OJB_TxBean - test():
> objSentMail.getSend_to() : " +
> objSentMail.getSend_to());
>   	logger.debug("OJB_TxBean - test():
> objSentMail.getRecipient() : " +
> objSentMail.getRecipient());
>   	
>   	logger.debug("OJB_TxBean - test(): objSentMail : "
> + objSentMail);
>   	db.deletePersistent(objSentMail);
>   	
>   	logger.debug("OJB_TxBean - test(): end");
> 	SimpleDateFormat simpleDateFormat = new
> SimpleDateFormat("dd.MM.yyyy hh:mm:ss");
>     return "OJB_TxBean - test(): done [" + 
> simpleDateFormat.format(Calendar.getInstance().getTime())
> + "]";
>   }
>   
> }
> --
> 
> 
> 
> 
> 
>  --- Armin Waibel <ar...@apache.org> ha scritto: 
> 
>>Hi Dino,
>>
>>Dino Di Cola wrote:
>>
>>
>>>Dear Armin,
>>>first of all thanks for your prompt reply!
>>>
>>>I applied the change to the
>>>ImplementationJTAImpl#registerOpenDatabase and
>>>executed the test from scratch. 
>>>My simple test application works fine now.
>>>I deployed also the main J2EE application and
>>
>>works
>>
>>>also there at first sight.
>>>
>>>I would like to have more insight from you
>>
>>regarding
>>
>>>the patch you proposed to apply in
>>>ImplementationJTAImpl class.
>>>
>>>1. You wrote the following: "OJB always lookup a
>>>running JTA-transaction this can't be successful
>>
>>when
>>
>>>db.open(...) is called on ejbCreate()".
>>>   Could you please give me more info? I cannot
>>
>>see
>>
>>>the problem with ejbCreate(). Thanks!
>>>
>>
>>ejbCreate() was called on session bean
>>initialization, this could be 
>>done e.g. at startup of your appServer to setup a
>>pool of session bean 
>>instances. Thus there is no guarantee that the
>>session bean was created 
>>in context of a running tx.
>>
>>
>>
>>>2. You wrote me it could be a "bug" in odmg
>>>implementation. And clearly you seems right. 
>>
>>I will fix this in CVS ASAP.
>>
>>
>>
>>>   I cannot understand however why it was
>>
>>successfully
>>
>>>running on previous versions of ora9ias!?!
>>>
>>
>>e.g. in your previous version your appServer doesn't
>>setup a session 
>>bean pool at startup, so the instances were created
>>when needed and thus 
>>when a tx was reachable --> no exception
>>
>>
>>
>>>3. I commented out the beginInternTransaction()
>>>invocation. Clearly this method is equally invoked
>>>following another code flow. 
>>>   Does it mean it was called twice before your
>>
>>patch?
>>
>>this could be the case, but it doesn't matter,
>>because 
>>beginInternTransaction() take care of this.
>>
>>
>>
>>>4. My Session Bean is substantially very close to
>>>
>>
>>src\ejb\org\apache\ojb\ejb\odmg\ODMGSessionBean.java
>>
>>>(taken from the db-ojb-1.0.rc7 distribution).
>>>   The only difference I note is on the "Required"
>>>attribute marked in the ODMGSessionBean.java
>>
>>javadoc.
>>
>>>I use "NotSupported" instead. 
>>>   Have I to change the attribute to "Required"?  
>>
>> 
>>
>>nearly all operations of the odmg-api have to be in
>>context of an 
>>transaction and in managed environments it's not
>>allowed to do OJB/ODMG 
>>related transaction demarcation, thus you always
>>have to use JTA 
>>transactions and the easiest way is to use
>>container-managed tx.
>>Alternative you can use bm-tx via UserTransaction.
>>I wonder how you could use odmg-api in managed
>>environment with 
>>transaction attribute "NotSupported"?
>>
>>
>>
>>>5. I am quite sure about this bug (anyway I will
>>
>>check
>>
>>>it more and more and I will keep you informed). 
>>>   If you are certain of this bug too, in what
>>
>>release
>>
>>>do you think to fix it? 
>>
>>Think the next upcoming OJB 1.0.1 will contain this
>>fix.
>>
>>
>>
>>>   Have you planned a target release date for next
>>
>>OJB
>>
>>>release?
>>
>>We planed a maintenance release 1.0.1 for last week
>>;-)
>>I'm sure we will release the new version in near
>>future.
>>
>>
>>
>>>   What can I do in the meantime a new release
>>
>>will be
>>
>>>officially distributed? 
>>>
>>
>>use the patched class
>>
>>
>>
>>>Armin, I really appreciated your help.
>>>Hope you will answer to all my questions without
>>>getting bored :)
>>>
>>
>>In return for services, never run down OJB ;-)
>>
>>regards,
>>Armin
>>
>>
>>
>>>Thanks, 
>>>
>>>d.
>>>--
>>>
>>>
>>>
>>>	
>>>
>>>	
>>>		
>>>
>>
> ____________________________________________________________
> 
>>>Yahoo! Companion - Scarica gratis la toolbar di
>>
>>Ricerca di Yahoo! 
>>
>>>http://companion.yahoo.it
>>>
>>>
>>
> ---------------------------------------------------------------------
> 
>>>To unsubscribe, e-mail:
>>
>>ojb-user-unsubscribe@db.apache.org
>>
>>>For additional commands, e-mail:
>>
>>ojb-user-help@db.apache.org
>>
>>>
>>>
>>
> ---------------------------------------------------------------------
> 
>>To unsubscribe, e-mail:
>>ojb-user-unsubscribe@db.apache.org
>>For additional commands, e-mail:
>>ojb-user-help@db.apache.org
>>
>> 
> 
> 
> 
> 	
> 
> 	
> 		
> ____________________________________________________________
> Yahoo! Companion - Scarica gratis la toolbar di Ricerca di Yahoo! 
> http://companion.yahoo.it
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
> 
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org

Re: Problems with TM in ejbCreate() --- continued

[Dino Di Cola <di...@yahoo.it>]

Dear Armin,

I am testing your patch on
ImplementationJTAImpl#registerOpenDatabase.
The problems regarding the ejbCreate() method
disappeared. Unfortunately I got some problems with
the org.odmg.Database#deletePersistent now.
Again this problem is related to Transaction
Management and was not present with the previous
Oracle9iAS 9.0.2.2 version. 

The test case I present here is again a simple J2EE
application made up of a test stateless session bean
with a single business method invoked via RMI.
The configuration is the same of the previous e-mail.
What I am trying to do is basically to lookup for an
object (es. SentMail) and deleting it with the
Database#deletePersistent method:

	/* this is done in ejbCreate()... */
  	org.odmg.Implementation odmg = OJB.getInstance();
	org.odmg.Database db = odmg.newDatabase();
        db.open(DEF_DATABASE_NAME,
Database.OPEN_READ_WRITE);    
	[...]

	/* this is done in the business method... */
	SentMail objSentMail = (SentMail)
lookupObject(SentMail.class, 4);
  	db.deletePersistent(objSentMail);

The object is actually found on the DB but when I try
to delete it I got the following exception:

     [exec] The following exception has been catched:
Transaction was rolled back:
org.odmg.TransactionNotInProgressException: No
transaction in progress, cannot delete persistent;
nested exception is:
     [exec]
com.evermind.server.rmi.OrionRemoteException:
Transaction was rolled back:
org.odmg.TransactionNotInProgressException: No
transaction in progress, cannot delete persistent
     [exec]
org.odmg.TransactionNotInProgressException: No
transaction in progress, cannot delete persistent
     [exec]     at
OJB_Tx_StatelessSessionBeanWrapper76.test(OJB_Tx_StatelessSessionBeanWrapper76.java:164)
     [exec]     at
java.lang.reflect.Method.invoke(Native Method)
     [exec]     at
com.evermind.server.rmi.RMICallHandler.run(RMICallHandler.java:119)
     [exec]     at
com.evermind.server.rmi.RMICallHandler.run(RMICallHandler.java:48)
     [exec]     at
EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:804)
     [exec]     at
java.lang.Thread.run(Thread.java:479)
     [exec]     at connection to c-01-091/10.2.20.20
as admin
     [exec]     at
com.evermind.server.rmi.RMIConnection.EXCEPTION_ORIGINATES_FROM_THE_REMOTE_SERVER(RMIConnection.java:1576)
     [exec]     at
com.evermind.server.rmi.RMIConnection.invokeMethod(RMIConnection.java:1529)
     [exec]     at
com.evermind.server.rmi.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:55)
     [exec]     at
com.evermind.server.rmi.RecoverableRemoteInvocationHandler.invoke(RecoverableRemoteInvocationHandler.java:22)
     [exec]     at
com.evermind.server.ejb.StatelessSessionRemoteInvocationHandler.invoke(StatelessSessionRemoteInvocationHandler.java:50)
     [exec]     at __Proxy5.test(Unknown Source)
     [exec]     at
it.enidata.psv.test.ejb.client.TestOJB_Tx.main(TestOJB_Tx.java:45)
     [exec]
     [exec]     Nested exception is:
     [exec]    
org.odmg.TransactionNotInProgressException: No
transaction in progress, cannot delete persistent
     [exec]     at
org.apache.ojb.odmg.DatabaseImpl.deletePersistent(Unknown
Source)
     [exec]     at
it.enidata.psv.test.ejb.OJB_TxBean.test(OJB_TxBean.java:144)
     [exec]     at
OJB_Tx_StatelessSessionBeanWrapper76.test(OJB_Tx_StatelessSessionBeanWrapper76.java:115)
     [exec]     at
java.lang.reflect.Method.invoke(Native Method)
     [exec]     at
com.evermind.server.rmi.RMICallHandler.run(RMICallHandler.java:119)
     [exec]     at
com.evermind.server.rmi.RMICallHandler.run(RMICallHandler.java:48)
     [exec]     at
EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:804)
     [exec]     at
java.lang.Thread.run(Thread.java:479)
     [exec]     at connection to
c-01-091.prirm.pride.it/10.2.20.20
     [exec]     at
com.evermind.server.rmi.OrionRemoteException.receive(OrionRemoteException.java:130)
     [exec]     at
com.evermind.server.rmi.RMIConnection.handleMethodInvocationResponse(RMIConnection.java:1691)
     [exec]     at
com.evermind.server.rmi.RMIConnection.run(RMIConnection.java:532)
     [exec]     at
com.evermind.server.rmi.RMIConnection.run(RMIConnection.java:275)
     [exec]     at
EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:798)
     [exec]     at
java.lang.Thread.run(Thread.java:484)

You can find the complete source code for the
OJB_TxBean here below. 

I am again in your hands... ;) 
Thanks in advance.

Regards,


Dino.


ps. (from previous thread...)
>> 3. I commented out the beginInternTransaction()
>> invocation. Clearly this method is equally invoked
>> following another code flow. Does it mean it was
called twice before your patch?
>
>this could be the case, but it doesn't matter,
because 
>beginInternTransaction() take care of this.
>
>nearly all operations of the odmg-api have to be in
context of a 
>transaction and in managed environments it's not
allowed to do OJB/ODMG 
>related transaction demarcation, thus you always have
to use JTA 
>transactions and the easiest way is to use
container-managed tx.
>Alternative you can use bm-tx via UserTransaction.
--
***********************************************************************
**** Source code for the session bean
*********************************
***********************************************************************
public class OJB_TxBean implements SessionBean {
	
  private SessionContext sessionContext;
  private static final String DEF_DATABASE_NAME =
"dsOJB";
  
  private Implementation odmg;
  private Database db;
  
  public OJB_TxBean() {}
  
  public void ejbActivate() {
  }
  
  public void ejbPassivate() {
  }
  
  public void ejbCreate() throws CreateException {
	  	try {
	  		init();
	  	} catch (InitException e) {
	  		throw new CreateException(e.getMessage());
	  	}  	
  }

  private void init() throws InitException{
  	/* ---------------------------- */
  	/* Step0 - Getting log4j logger */
  	/* ---------------------------- */
  	Logger logger =
Logger.getLogger("psv.j2ee.testing");
  	logger.debug("OJB_TxBean - init(): begin");
  	 
  	odmg = null;
  	db = null; 	 
  	
  	/* ------------------------------------ */
  	/* Step1 - Initializing ODMG connection */
  	/* ------------------------------------ */
  	 logger.debug("OJB_TxBean - init(): initializing
ODMG connection [BEGIN]");
  	 odmg = OJB.getInstance();

  	 logger.debug("OJB_TxBean - init():
odmg.newDatabase()");
  	 db = odmg.newDatabase();
  	 
  	 try {
  	 	logger.debug("OJB_TxBean - init(): open new
database " + db + " using databaseName name " +
DEF_DATABASE_NAME);
  	 	db.open(DEF_DATABASE_NAME,
Database.OPEN_READ_WRITE);            
  	 } catch (ODMGException e) {
  	 	logger.error("OJB_TxBean - init(): Database open
failed", e);
  	 	throw new InitException(e.getMessage());
  	 } 
  	 
  	 logger.debug("OJB_TxBean - init(): initializing
ODMG connection [END]");  
  }
  
  public void ejbRemove() {
  	Logger logger =
Logger.getLogger("psv.j2ee.testing");
  	logger.debug("OJB_TxBean - ejbRemove(): closing
ODMG connection [BEGIN]");
  	try {
  		logger.debug("OJB_TxBean - ejbRemove():
db.close(): " +  db);
  		if (db != null) db.close();
  	} catch (ODMGException e) {
  		logger.error("OJB_TxBean - ejbRemove(): closing of
database failed", e);
  	}  	
  	db = null;
  	odmg = null;
  	logger.debug("OJB_TxBean - ejbRemove(): closing
ODMG connection [END]"); 
  }
  
  public void setSessionContext(SessionContext
sessionContext) {
    this.sessionContext = sessionContext;
  }
  
  protected PObject lookupObject(Class target, long
oid) {
  	Logger logger =
Logger.getLogger("psv.j2ee.testing"); 
  	logger.debug("OJB_TxBean - lookupObject(): begin");
  	
  	PersistenceBroker broker = null;
  	PObject pObject = null;

  	try {
  		broker =
PersistenceBrokerFactory.defaultPersistenceBroker();

  		Criteria crit = new Criteria();
  		crit.addEqualTo("oid", new Long(oid));
  		Query query = new QueryByCriteria(target, crit);

  		java.util.Iterator iter =
broker.getCollectionByQuery(query).iterator();

  		if (iter.hasNext()) pObject = (PObject)
iter.next();
  	} catch (Exception e) {
  		logger.error("OJB_TxBean -  lookupObject(): Query
failed", e);
  		throw new EJBException("OJB_TxBean - 
lookupObject(): Query failed", e);
  	} finally {
  		if (broker != null)
  			broker.close();
  	}
  	
  	logger.debug("OJB_TxBean - lookupObject(): end");
  	return pObject;
  }
  
  public String test() throws java.rmi.RemoteException
{
  	Logger logger =
Logger.getLogger("psv.j2ee.testing"); 
  	logger.debug("OJB_TxBean - test(): begin");
  	
  	/* ---------------------- */
  	/* --- Business Stuff --- */
  	/* ---------------------- */
  	logger.debug("OJB_TxBean - test(): odmg : " +
odmg);
  	SentMail objSentMail = (SentMail)
lookupObject(SentMail.class, 4);
  	logger.debug("OJB_TxBean - test(): objSentMail : "
+ objSentMail);
  	logger.debug("OJB_TxBean - test():
objSentMail.getSubject() : " +
objSentMail.getSubject());
  	logger.debug("OJB_TxBean - test():
objSentMail.getSend_to() : " +
objSentMail.getSend_to());
  	logger.debug("OJB_TxBean - test():
objSentMail.getRecipient() : " +
objSentMail.getRecipient());
  	
  	logger.debug("OJB_TxBean - test(): objSentMail : "
+ objSentMail);
  	db.deletePersistent(objSentMail);
  	
  	logger.debug("OJB_TxBean - test(): end");
	SimpleDateFormat simpleDateFormat = new
SimpleDateFormat("dd.MM.yyyy hh:mm:ss");
    return "OJB_TxBean - test(): done [" + 
simpleDateFormat.format(Calendar.getInstance().getTime())
+ "]";
  }
  
}
--





 --- Armin Waibel <ar...@apache.org> ha scritto: 
> Hi Dino,
> 
> Dino Di Cola wrote:
> 
> > Dear Armin,
> > first of all thanks for your prompt reply!
> > 
> > I applied the change to the
> > ImplementationJTAImpl#registerOpenDatabase and
> > executed the test from scratch. 
> > My simple test application works fine now.
> > I deployed also the main J2EE application and
> works
> > also there at first sight.
> > 
> > I would like to have more insight from you
> regarding
> > the patch you proposed to apply in
> > ImplementationJTAImpl class.
> > 
> > 1. You wrote the following: "OJB always lookup a
> > running JTA-transaction this can't be successful
> when
> > db.open(...) is called on ejbCreate()".
> >    Could you please give me more info? I cannot
> see
> > the problem with ejbCreate(). Thanks!
> > 
> 
> ejbCreate() was called on session bean
> initialization, this could be 
> done e.g. at startup of your appServer to setup a
> pool of session bean 
> instances. Thus there is no guarantee that the
> session bean was created 
> in context of a running tx.
> 
> 
> > 2. You wrote me it could be a "bug" in odmg
> > implementation. And clearly you seems right. 
> 
> I will fix this in CVS ASAP.
> 
> 
> >    I cannot understand however why it was
> successfully
> > running on previous versions of ora9ias!?!
> > 
> 
> e.g. in your previous version your appServer doesn't
> setup a session 
> bean pool at startup, so the instances were created
> when needed and thus 
> when a tx was reachable --> no exception
> 
> 
> > 3. I commented out the beginInternTransaction()
> > invocation. Clearly this method is equally invoked
> > following another code flow. 
> >    Does it mean it was called twice before your
> patch?
> >
> 
> this could be the case, but it doesn't matter,
> because 
> beginInternTransaction() take care of this.
> 
> 
> > 4. My Session Bean is substantially very close to
> >
> src\ejb\org\apache\ojb\ejb\odmg\ODMGSessionBean.java
> > (taken from the db-ojb-1.0.rc7 distribution).
> >    The only difference I note is on the "Required"
> > attribute marked in the ODMGSessionBean.java
> javadoc.
> > I use "NotSupported" instead. 
> >    Have I to change the attribute to "Required"?  
>  
> > 
> 
> nearly all operations of the odmg-api have to be in
> context of an 
> transaction and in managed environments it's not
> allowed to do OJB/ODMG 
> related transaction demarcation, thus you always
> have to use JTA 
> transactions and the easiest way is to use
> container-managed tx.
> Alternative you can use bm-tx via UserTransaction.
> I wonder how you could use odmg-api in managed
> environment with 
> transaction attribute "NotSupported"?
> 
> 
> > 5. I am quite sure about this bug (anyway I will
> check
> > it more and more and I will keep you informed). 
> >    If you are certain of this bug too, in what
> release
> > do you think to fix it? 
> 
> Think the next upcoming OJB 1.0.1 will contain this
> fix.
> 
> 
> >    Have you planned a target release date for next
> OJB
> > release?
> 
> We planed a maintenance release 1.0.1 for last week
> ;-)
> I'm sure we will release the new version in near
> future.
> 
> 
> >    What can I do in the meantime a new release
> will be
> > officially distributed? 
> > 
> 
> use the patched class
> 
> 
> > Armin, I really appreciated your help.
> > Hope you will answer to all my questions without
> > getting bored :)
> > 
> 
> In return for services, never run down OJB ;-)
> 
> regards,
> Armin
> 
> 
> > Thanks, 
> > 
> > d.
> > --
> > 
> > 
> > 
> > 	
> > 
> > 	
> > 		
> >
>
____________________________________________________________
> > Yahoo! Companion - Scarica gratis la toolbar di
> Ricerca di Yahoo! 
> > http://companion.yahoo.it
> > 
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> ojb-user-unsubscribe@db.apache.org
> > For additional commands, e-mail:
> ojb-user-help@db.apache.org
> > 
> > 
> > 
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail:
> ojb-user-help@db.apache.org
> 
>  


	

	
		
____________________________________________________________
Yahoo! Companion - Scarica gratis la toolbar di Ricerca di Yahoo! 
http://companion.yahoo.it

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org

Re: Problems with TM in ejbCreate()

[Armin Waibel <ar...@apache.org>]

Hi Dino,

Dino Di Cola wrote:

> Dear Armin,
> first of all thanks for your prompt reply!
> 
> I applied the change to the
> ImplementationJTAImpl#registerOpenDatabase and
> executed the test from scratch. 
> My simple test application works fine now.
> I deployed also the main J2EE application and works
> also there at first sight.
> 
> I would like to have more insight from you regarding
> the patch you proposed to apply in
> ImplementationJTAImpl class.
> 
> 1. You wrote the following: "OJB always lookup a
> running JTA-transaction this can't be successful when
> db.open(...) is called on ejbCreate()".
>    Could you please give me more info? I cannot see
> the problem with ejbCreate(). Thanks!
> 

ejbCreate() was called on session bean initialization, this could be 
done e.g. at startup of your appServer to setup a pool of session bean 
instances. Thus there is no guarantee that the session bean was created 
in context of a running tx.


> 2. You wrote me it could be a "bug" in odmg
> implementation. And clearly you seems right. 

I will fix this in CVS ASAP.


>    I cannot understand however why it was successfully
> running on previous versions of ora9ias!?!
> 

e.g. in your previous version your appServer doesn't setup a session 
bean pool at startup, so the instances were created when needed and thus 
when a tx was reachable --> no exception


> 3. I commented out the beginInternTransaction()
> invocation. Clearly this method is equally invoked
> following another code flow. 
>    Does it mean it was called twice before your patch?
>

this could be the case, but it doesn't matter, because 
beginInternTransaction() take care of this.


> 4. My Session Bean is substantially very close to
> src\ejb\org\apache\ojb\ejb\odmg\ODMGSessionBean.java
> (taken from the db-ojb-1.0.rc7 distribution).
>    The only difference I note is on the "Required"
> attribute marked in the ODMGSessionBean.java javadoc.
> I use "NotSupported" instead. 
>    Have I to change the attribute to "Required"?    
> 

nearly all operations of the odmg-api have to be in context of an 
transaction and in managed environments it's not allowed to do OJB/ODMG 
related transaction demarcation, thus you always have to use JTA 
transactions and the easiest way is to use container-managed tx.
Alternative you can use bm-tx via UserTransaction.
I wonder how you could use odmg-api in managed environment with 
transaction attribute "NotSupported"?


> 5. I am quite sure about this bug (anyway I will check
> it more and more and I will keep you informed). 
>    If you are certain of this bug too, in what release
> do you think to fix it? 

Think the next upcoming OJB 1.0.1 will contain this fix.


>    Have you planned a target release date for next OJB
> release?

We planed a maintenance release 1.0.1 for last week ;-)
I'm sure we will release the new version in near future.


>    What can I do in the meantime a new release will be
> officially distributed? 
> 

use the patched class


> Armin, I really appreciated your help.
> Hope you will answer to all my questions without
> getting bored :)
> 

In return for services, never run down OJB ;-)

regards,
Armin


> Thanks, 
> 
> d.
> --
> 
> 
> 
> 	
> 
> 	
> 		
> ____________________________________________________________
> Yahoo! Companion - Scarica gratis la toolbar di Ricerca di Yahoo! 
> http://companion.yahoo.it
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
> 
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org

Re: Problems with TM in ejbCreate()

[Dino Di Cola <di...@yahoo.it>]

Dear Armin,
first of all thanks for your prompt reply!

I applied the change to the
ImplementationJTAImpl#registerOpenDatabase and
executed the test from scratch. 
My simple test application works fine now.
I deployed also the main J2EE application and works
also there at first sight.

I would like to have more insight from you regarding
the patch you proposed to apply in
ImplementationJTAImpl class.

1. You wrote the following: "OJB always lookup a
running JTA-transaction this can't be successful when
db.open(...) is called on ejbCreate()".
   Could you please give me more info? I cannot see
the problem with ejbCreate(). Thanks!

2. You wrote me it could be a "bug" in odmg
implementation. And clearly you seems right. 
   I cannot understand however why it was successfully
running on previous versions of ora9ias!?!

3. I commented out the beginInternTransaction()
invocation. Clearly this method is equally invoked
following another code flow. 
   Does it mean it was called twice before your patch?

4. My Session Bean is substantially very close to
src\ejb\org\apache\ojb\ejb\odmg\ODMGSessionBean.java
(taken from the db-ojb-1.0.rc7 distribution).
   The only difference I note is on the "Required"
attribute marked in the ODMGSessionBean.java javadoc.
I use "NotSupported" instead. 
   Have I to change the attribute to "Required"?    

5. I am quite sure about this bug (anyway I will check
it more and more and I will keep you informed). 
   If you are certain of this bug too, in what release
do you think to fix it? 
   Have you planned a target release date for next OJB
release?
   What can I do in the meantime a new release will be
officially distributed? 

Armin, I really appreciated your help.
Hope you will answer to all my questions without
getting bored :)

Thanks, 

d.
--



	

	
		
____________________________________________________________
Yahoo! Companion - Scarica gratis la toolbar di Ricerca di Yahoo! 
http://companion.yahoo.it

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org

Re: Problems with TM in ejbCreate()

[Armin Waibel <ar...@apache.org>]

Hi Dino,

Nested exception is:
 > 	org.odmg.TransactionNotInProgressException: No
 > external transaction found
 >         at
 > org.apache.ojb.odmg.JTATxManager.registerTx(Unknown
 > Source)

Seems OJB can't lookup a JTA transaction from the appServer. I think 
this could be a bug in odmg implementation. In method

ImplementationJTAImpl#registerOpenDatabase

OJB always lookup a running JTA-transaction this can't be successful 
when db.open(...) is called on ejbCreate(). Please try to comment out 
the line for transaction lookup and run your test again.

protected synchronized void registerOpenDatabase(DatabaseImpl newDB)
{
    super.registerOpenDatabase(newDB);
    // we shouldn't search for tx when open the database
    // beginInternTransaction();
}

regards,
Armin


Dino Di Cola wrote:

> Dear all,
> I encountered some problems with Transaction
> Management porting my J2EE application from Ora9ias
> 9.0.2 to Ora9ias 9.0.3 platform.
> I tried to reproduce the problem with a simple J2EE
> application made up of a test stateless session bean
> with a single business method.
> This very simple J2EE application is deployed
> successfully both in Ora9ias 9.0.2 and Ora9ias 9.0.3.
> The business method (test_odmg()) can be successfully
> invoked by a RMI client on the Ora9ias 9.0.2
> deployment.
> On the Ora9ias 9.0.3 deployment however I get the
> following error:
> 
> The following exception has been catched: Error in
> ejbCreate(): No external transaction found; nested
> exception is:
>         org.odmg.TransactionNotInProgressException: No
> external transaction found
> 	com.evermind.server.rmi.OrionRemoteException: Error
> in ejbCreate(): No external transaction found
>         at
> com.evermind.server.ejb.StatelessSessionEJBHome.getContextInstance(StatelessSessionEJBHome.java:267)
>         at
> OJBTest_ODMG_StatelessSessionBeanWrapper52.test_odmg(OJBTest_ODMG_StatelessSessionBeanWrapper52.java:83)
>         at java.lang.reflect.Method.invoke(Native
> Method)
>         at
> com.evermind.server.rmi.RMICallHandler.run(RMICallHandler.java:119)
>         at
> com.evermind.server.rmi.RMICallHandler.run(RMICallHandler.java:48)
>         at
> EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:803)
>         at java.lang.Thread.run(Thread.java:479)
> 	at connection to c99-012.prirm.pride.it/10.2.21.8 as
> admin
>         at
> com.evermind.server.rmi.RMIConnection.EXCEPTION_ORIGINATES_FROM_THE_REMOTE_SERVER(RMIConnection.java:1558)
>         at
> com.evermind.server.rmi.RMIConnection.invokeMethod(RMIConnection.java:1511)
>         at
> com.evermind.server.rmi.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:55)
>         at
> com.evermind.server.rmi.RecoverableRemoteInvocationHandler.invoke(RecoverableRemoteInvocationHandler.java:22)
>         at
> com.evermind.server.ejb.StatelessSessionRemoteInvocationHandler.invoke(StatelessSessionRemoteInvocationHandler.java:50)
>         at __Proxy4.test_odmg(Unknown Source)
>         at
> it.enidata.psv.ejb.client.TestOJB_ODMG.main(TestOJB_ODMG.java:45)
> 
>         Nested exception is:
> 	org.odmg.TransactionNotInProgressException: No
> external transaction found
>         at
> org.apache.ojb.odmg.JTATxManager.registerTx(Unknown
> Source)
>         at
> org.apache.ojb.odmg.TransactionImpl.begin(Unknown
> Source)
>         at
> org.apache.ojb.odmg.ImplementationJTAImpl.beginInternTransaction(Unknown
> Source)
>         at
> org.apache.ojb.odmg.ImplementationJTAImpl.registerOpenDatabase(Unknown
> Source)
>         at
> org.apache.ojb.odmg.DatabaseImpl.open(Unknown Source)
>         at
> it.enidata.psv.ejb.account.OJBTest_ODMGBean.init(OJBTest_ODMGBean.java:99)
>         at
> it.enidata.psv.ejb.account.OJBTest_ODMGBean.ejbCreate(OJBTest_ODMGBean.java:41)
>         at
> OJBTest_ODMGHome_StatelessSessionHomeWrapper53.callCreate(OJBTest_ODMGHome_StatelessSessionHomeWrapper53.java:145)
>         at
> com.evermind.server.ejb.StatelessSessionEJBHome.getContextInstance(StatelessSessionEJBHome.java:254)
>         at
> OJBTest_ODMG_StatelessSessionBeanWrapper52.test_odmg(OJBTest_ODMG_StatelessSessionBeanWrapper52.java:83)
>         at java.lang.reflect.Method.invoke(Native
> Method)
>         at
> com.evermind.server.rmi.RMICallHandler.run(RMICallHandler.java:119)
>         at
> com.evermind.server.rmi.RMICallHandler.run(RMICallHandler.java:48)
>         at
> EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:803)
>         at java.lang.Thread.run(Thread.java:479)
> 	at connection to c99-012.prirm.pride.it/10.2.21.8
>         at
> com.evermind.server.rmi.OrionRemoteException.receive(OrionRemoteException.java:130)
>         at
> com.evermind.server.rmi.RMIConnection.handleMethodInvocationResponse(RMIConnection.java:1673)
>         at
> com.evermind.server.rmi.RMIConnection.run(RMIConnection.java:532)
>         at
> com.evermind.server.rmi.RMIConnection.run(RMIConnection.java:275)
>         at
> EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:797)
>         at java.lang.Thread.run(Thread.java:484)
> 
> The error arises in the ejbCreate() as soon as the
> db.open() is invoked. 
> - If I move the OJB initialization into the business
> method (leaving the EJB as "stateless") the error
> disappears.
> - If I change the deployment descriptor from
> "stateless" to "stateful" (leaving the OJB
> initialization into the ejbCreate()) the error
> disappears.
> What is the rationale behind this behaviour?
> 
> Here below you will find 
> - the source code of the test session bean
> - the deployment descriptor
> - the OJB.properties
> 
> Any assitance in the matter would be great. 
> Thanks in advance.
> 
> Regards,
> 
> 
> Dino.
> --
> 
> ***********************************************************************
> **** Source code for the session bean
> *********************************
> ***********************************************************************
> public class OJBTest_ODMGBean implements SessionBean {
> 	
>   private SessionContext sessionContext;
>   private static final String DEF_DATABASE_NAME =
> "dsOJB";
>   
>   private Implementation odmg;
>   private Database db;
>   
>   public OJBTest_ODMGBean() {}
>   
>   public void ejbActivate() {
>   }
>   
>   public void ejbPassivate() {
>   }
>   
>   public void ejbCreate() throws CreateException {
>   	try {
>   		init();
>   	} catch (InitException e) {
>   		throw new CreateException(e.getMessage());
>   	}  	
>   }
> 
>   private void init() throws InitException{
>   	Logger logger =
> Logger.getLogger("psv.j2ee.testing");
>   	logger.debug("OJBTest_ODMGBean - test_odmg():
> begin");
> 
> 	logger.debug("OJBTest_ODMGBean - test_odmg():
> initializing ODMG connection [BEGIN]");
>  
> 	logger.debug("OJBTest_ODMGBean - test_odmg():
> OJB.getInstance()");
> 	odmg = OJB.getInstance();  	 
> 	logger.debug("OJBTest_ODMGBean - test_odmg(): found
> Implementation instance [" + odmg + "]");
> 	
> 	logger.debug("OJBTest_ODMGBean - test_odmg():
> odmg.newDatabase()");
> 	db = odmg.newDatabase();
>   	 
> 	try {
> 		logger.debug("OJBTest_ODMGBean - test_odmg(): open
> new database " + db + " using databaseName name " +
> DEF_DATABASE_NAME);
> 		db.open(DEF_DATABASE_NAME,
> Database.OPEN_READ_WRITE);            
> 	} catch (ODMGException e) {
> 		logger.error("OJBTest_ODMGBean - test_odmg():
> Database open failed", e);
> 		throw new InitException(e.getMessage());
> 	} 
> 	
> 	logger.debug("OJBTest_ODMGBean - test_odmg():
> initializing ODMG connection [END]");	
>   }
>   
>   public void ejbRemove() {
>   	Logger logger =
> Logger.getLogger("psv.j2ee.testing");
>   	logger.debug("OJBTest_ODMGBean - ejbRemove():
> closing ODMG connection [BEGIN]");
>   	try {
>   		logger.debug("OJBTest_ODMGBean - ejbRemove():
> db.close(): " +  db);
>   		if (db != null) db.close();
>   	} catch (ODMGException e) {
>   		logger.error("OJBTest_ODMGBean - ejbRemove():
> closing of database failed", e);
>   	}  	
>   	db = null;
>   	odmg = null;
>   	logger.debug("OJBTest_ODMGBean - ejbRemove():
> closing ODMG connection [END]"); 
>   }
>   
>   public void setSessionContext(SessionContext
> sessionContext) {
>     this.sessionContext = sessionContext;
>   }
>   
>   public String test_odmg() throws
> java.rmi.RemoteException {
>   	Logger logger =
> Logger.getLogger("psv.j2ee.testing");  	
>   	logger.debug("OJBTest_ODMGBean - test_odmg():
> end");
> 	SimpleDateFormat simpleDateFormat = new
> SimpleDateFormat("dd.MM.yyyy hh:mm:ss");
>     	return "OJBTest_ODMGBean - test_odmg(): done [" +
> 
> simpleDateFormat.format(Calendar.getInstance().getTime())
> + "]";
>   }
>   
> }
> 
> 
> ***********************************************************************
> **** Deployment descriptor
> ********************************************
> ***********************************************************************
> <?xml version="1.0" encoding="UTF-8"?>
> <ejb-jar>
>   <enterprise-beans>
>     <session>
>       <ejb-name>OJBTest_ODMG</ejb-name>
>      
> <home>it.enidata.psv.ejb.account.OJBTest_ODMGHome</home>
>      
> <remote>it.enidata.psv.ejb.account.OJBTest_ODMG</remote>
>      
> <ejb-class>it.enidata.psv.ejb.account.OJBTest_ODMGBean</ejb-class>
>       <session-type>Stateless</session-type>
>       <transaction-type>Container</transaction-type>
>     </session>
>   </enterprise-beans>
>   <assembly-descriptor>
>     <container-transaction>
>       <method>
>         <ejb-name>OJBTest_ODMG</ejb-name>
>         <method-name>*</method-name>
>       </method>
>       <trans-attribute>NotSupported</trans-attribute>
>     </container-transaction>
>   </assembly-descriptor>
> </ejb-jar>
> 
> ***********************************************************************
> **** OJB.properties
> ***************************************************
> ***********************************************************************
> #<!--
> #/* Copyright 2002-2004 The Apache Software Foundation
> # *
> # * Licensed under the Apache License, Version 2.0
> (the "License");
> # * you may not use this file except in compliance
> with the License.
> # * You may obtain a copy of the License at
> # *
> # *     http://www.apache.org/licenses/LICENSE-2.0
> # *
> # * Unless required by applicable law or agreed to in
> writing, software
> # * distributed under the License is distributed on an
> "AS IS" BASIS,
> # * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND,
> either express or implied.
> # * See the License for the specific language
> governing permissions and
> # * limitations under the License.
> # */
> #-->
> # OJB.properties -- configuration of the OJB runtime
> environment 
> # Version: 1.0
> # (c) 2001, 2002, 2003 Apache Software Foundation
> # Author: Thomas Mahler and many others
> # @version $Id: OJB.properties,v 1.2 2004/07/19
> 13:52:56 d.dicola Exp $
> #
> #----------------------------------------------------------------------------------------
> # repository file settings
> #----------------------------------------------------------------------------------------
> # The repositoryFile entry tells OJB to use this file
> as as its standard mapping
> # repository. The file is looked up from the
> classpath.
> #
> repositoryFile=repository.xml
> #
> # If the useSerializedRepository entry is set to true,
> OJB tries to load a
> # serialized version of the repository for performance
> reasons.
> # if set to false, OJB always loads the xml file.
> # Setting this flag to true will accelerate the
> startup sequence of OJB.
> # If set to true changes to the repository.xml file
> will only be detected
> # after maually deleting the repository.xml.serialized
> file.
> useSerializedRepository=false
> #
> # If Repository serialization is used the entry
> serializedRepositoryPath defines the
> # directory where the Repository is written to and
> read from.
> # this entry is used only when the
> useSerializedRepository flag is set to true
> #
> serializedRepositoryPath=.
> #
> #----------------------------------------------------------------------------------------
> # PersistenceBrokerFactory / PersistenceBroker
> #----------------------------------------------------------------------------------------
> # The PersistenceBrokerFactoryClass entry decides
> which concrete
> # PersistenceBrokerFactory implemention is to be used.
> PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl
> # If in managed environment *only* the PB-api was used
> it's recommended to use this factory
> # to enable the PersistenceBroker instances to
> participate in the JTA transaction. This makes
> # e.g. PBStateListener work properly in managed
> environments.
> #PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactorySyncImpl
> #
> #
> # The PersistenceBrokerClass entry decides which
> concrete PersistenceBroker
> # implementation is to be served by the
> PersistenceBrokerFactory.
> # This is the singlevm implementation:
> PersistenceBrokerClass=org.apache.ojb.broker.core.PersistenceBrokerImpl
> #
> # This is an implementation that uses Prevayler
> (prevayler.sf.net) as the persistent storage.
> # Using this implementation OJB works as a simple
> OODBMS
> #PersistenceBrokerClass=org.apache.ojb.broker.prevayler.PBPrevaylerImpl
> #
> #----------------------------------------------------------------------------------------
> # PersistenceBroker pool
> #----------------------------------------------------------------------------------------
> # PersistenceBroker pool configuration
> # This pool uses the jakarta-commons-pool api.
> # There you can find things described in detail.
> #
> # maximum number of brokers that can be borrowed from
> the
> # pool at one time. When non-positive, there is no
> limit.
> maxActive=100
> #
> # controls the maximum number of brokers that can sit
> idle in the
> # pool (per key) at any time. When non-positive, there
> is no limit
> maxIdle=-1
> #
> # max time block to get broker instance from pool,
> after that exception is thrown.
> # When non-positive, block till last judgement
> maxWait=2000
> #
> # indicates how long the eviction thread should sleep
> before "runs" of examining
> # idle objects. When non-positive, no eviction thread
> will be launched.
> timeBetweenEvictionRunsMillis=-1
> #
> # specifies the minimum amount of time that an broker
> may sit idle
> # in the pool before it is eligable for eviction due
> to idle time.
> # When non-positive, no object will be dropped from
> the pool due
> # to idle time alone (depends on
> timeBetweenEvictionRunsMillis > 0)
> minEvictableIdleTimeMillis=1000000
> #
> # specifies the behaviour of the pool when broker
> capacity is
> # exhausted (see maxActive above)
> # 0 - fail
> # 1 - block
> # 2 - grow
> whenExhaustedAction=0
> #
> #
> #----------------------------------------------------------------------------------------
> # ConnectionFactory / Default ConnectionPool
> #----------------------------------------------------------------------------------------
> # The ConnectionFactoryClass entry determines which
> kind of ConnectionFactory
> # is to be used within org.apache.ojb as connection
> factory.
> # A ConnectionFactory is responsible for creating
> # JDBC Connections. Current version ships four
> implementations:
> #
> # 1. ConnectionFactoryNotPooledImpl
> #    No pooling, no playing around.
> #    Every connection request returns a new
> connection,
> #    every connection release close the connection.
> # 2. ConnectionFactoryPooledImpl
> #    This implementation supports connection pooling.
> # 3. ConnectionFactoryDBCPImpl
> #    Using the jakarta-DBCP api for connection
> management, support
> #    connection- and prepared statement-pooling,
> abandoned connection handling.
> # 4. ConnectionFactoryManagedImpl
> #    Connection factory for use within managed
> environments - e.g. JBoss.
> #    Every obtained DataSource was wrapped within OJB
> (and ignore
> #    e.g. con.commit() calls within OJB).
> #    Use this implementation e.g if you use
> Datasources from an application server.
> #
> # Use the OJB performance tests to decide, which
> implementation is best for you.
> # The proper way of obtaining a connection is
> configured in
> # JDBCConnectionDescriptor entries in the
> repository.xml file.
> # If want a more fine grained control of each
> connection pool used by OJB,
> # take a look at the repository.dtd, there was a
> possibility to override
> # this default connection factory entry in each
> JDBCConnectionDescriptor.
> #
> #ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl
> #ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryNotPooledImpl
> ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryManagedImpl
> #ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryDBCPImpl
> #
> #
> #----------------------------------------------------------------------------------------
> # ConnectionManager
> #----------------------------------------------------------------------------------------
> # The ConnectionManagerClass entry defines the
> ConnectionManager implemementation to be used
> ConnectionManagerClass=org.apache.ojb.broker.accesslayer.ConnectionManagerImpl
> #
> #
> #----------------------------------------------------------------------------------------
> # SqlGenerator
> #----------------------------------------------------------------------------------------
> # The SqlGeneratorClass entry defines the SqlGenerator
> implemementation to be used
> SqlGeneratorClass=org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl
> #
> #
> #----------------------------------------------------------------------------------------
> # IndirectionHandler
> #----------------------------------------------------------------------------------------
> # The IndirectionHandlerClass entry defines the class
> to be used by OJB's proxies to
> # handle method invocations
> #
> IndirectionHandlerClass=org.apache.ojb.broker.core.proxy.IndirectionHandlerDefaultImpl
> #
> #----------------------------------------------------------------------------------------
> # ListProxy
> #----------------------------------------------------------------------------------------
> # The ListProxyClass entry defines the proxy class to
> be used for collections that
> # implement the java.util.List interface.
> #
> ListProxyClass=org.apache.ojb.broker.core.proxy.ListProxyDefaultImpl
> #
> #----------------------------------------------------------------------------------------
> # SetProxy
> #----------------------------------------------------------------------------------------
> # The SetProxyClass entry defines the proxy class to
> be used for collections that
> # implement the java.util.Set interface.
> #
> SetProxyClass=org.apache.ojb.broker.core.proxy.SetProxyDefaultImpl
> #
> #----------------------------------------------------------------------------------------
> # CollectionProxy
> #----------------------------------------------------------------------------------------
> # The CollectionProxyClass entry defines the proxy
> class to be used for collections that
> # do not implement java.util.List or java.util.Set.
> #
> CollectionProxyClass=org.apache.ojb.broker.core.proxy.CollectionProxyDefaultImpl
> #
> #----------------------------------------------------------------------------------------
> # StatementManager
> #----------------------------------------------------------------------------------------
> # The StatementManagerClass entry defines the
> StatementManager implemementation to be used
> StatementManagerClass=org.apache.ojb.broker.accesslayer.StatementManager
> #
> #
> #----------------------------------------------------------------------------------------
> # StatementsForClass
> #----------------------------------------------------------------------------------------
> # The StatementsForClassClass entry defines the
> StatementsForClass implemementation to be used
> # to implement cached statements.
> StatementsForClassClass=org.apache.ojb.broker.accesslayer.StatementsForClassImpl
> #
> #
> #----------------------------------------------------------------------------------------
> # JdbcAccess
> #----------------------------------------------------------------------------------------
> # The JdbcAccessClass entry defines the JdbcAccess
> implemementation to be used
> JdbcAccessClass=org.apache.ojb.broker.accesslayer.JdbcAccessImpl
> #
> #
> #----------------------------------------------------------------------------------------
> # Object cache
> #----------------------------------------------------------------------------------------
> # The ObjectCacheClass entry tells OJB which concrete
> ObjectCache
> # implementation is to be used as standard cache.
> # Its also possible to override this entry adding
> object-cache elements
> # on jdbc-connection-descriptor level and
> # per class-descriptor in repository file. More info
> see documentation.
> #
> ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheDefaultImpl
> #ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheEmptyImpl
> #ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCachePerBrokerImpl
> #ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheJCSPerClassImpl
> #ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCachePerClassImpl
> #
> #
> # This property is only relevant if the per
> class-descriptor object-cache
> # declaration was used in conjunction with metadata
> runtime changes.
> # If set 'flase' the class name of the object is used
> # to find a per class ObjectCache implementation.
> # If set 'true' the ObjectCacheDescriptor instance is
> used as key to
> # find a per class ObjectCache, this enables to use
> different ObjectCache
> # instances for the same class.
> descriptorBasedCaches=false
> #
> #
> # Use CacheFilters to do filter operations before
> caching methods were
> # called. Build your own filter class by implementing
> org.apache.ojb.cache.CacheFilter.
> # It is possible to use a arbitrary number of
> CacheFilters, but this slows
> # down the performance of the cache, thus handle with
> care.
> #
> # - org.apache.ojb.broker.cache.CacheFilterClassImpl
> # allows filtering of classes
> # - org.apache.ojb.broker.cache.CacheFilterPackageImpl
> # allows filtering of packages
> # More info see Javadoc of the according classes.
> # Set a comma separated list of CacheFilter.
> #ObjectCacheFilter=org.apache.ojb.broker.cache.CacheFilterClassImpl,org.apache.ojb.broker.cache.CacheFilterPackageImpl
> #
> #----------------------------------------------------------------------------------------
> # Locking
> #----------------------------------------------------------------------------------------
> # The LockManagerClass entry tells OJB which concrete
> LockManager
> # implementation is to be used.
> LockManagerClass=org.apache.ojb.odmg.locking.LockManagerDefaultImpl
> #
> # The LockMapClass entry tells OJB which concrete
> LockMap
> # implementation is to be used.
> # If OJB is running on multiple concurrent clients it
> is recommended
> # to use the RemoteLockMapImpl. It guarantees to
> provide
> # Lockmanagement across multiple JVMs.
> # This Implemenation relies on a Servlet based
> Lockserver. To use it you have to
> # deploy the ojb-lockserver.war into a Servlet engine.
> # and you have to set the Property LockServletUrl to
> point to this servlet.
> # (see LockServletUrl section below).
> # If OJB is running in a single JVM (e.g. in a desktop
> app, or in a servlet
> # engine) it is save to use the InMemoryLockMapImpl.
> Using it will result
> # in a large performance gain.
> #LockMapClass=org.apache.ojb.odmg.locking.RemoteLockMapImpl
> LockMapClass=org.apache.ojb.odmg.locking.InMemoryLockMapImpl
> #
> # The LockTimeout entry defines the maximum time in
> milliseconds
> # that a lock may be hold. Defaults to 60000 = 1
> minute
> LockTimeout=60000
> #
> # The ImplicitLocking entry defines if implicit lock
> acquisition is
> # to be used. If set to true OJB implicitely locks
> objects to ODMG
> # transactions after performing OQL queries.
> # If implicit locking is used locking objects is
> recursive, that is
> # associated objects are also locked.
> # If ImplicitLocking is set to false, no locks are
> obtained in OQL
> # queries and there is also no recursive locking.
> ImplicitLocking=true
> #ImplicitLocking=false
> #
> #
> # The LockServletUrl entry points to the Lockserver
> servlet.
> # This Servlet is addressed by all distributed JVMs if
> the RemoteLockMapImpl
> # is used.
> LockServletUrl=http://127.0.0.1:8080/ojb-lockserver
> #
> #
> # The LockAssociations entry defines the behaviour for
> the OJB
> # implicit locking feature. If set to WRITE (default)
> acquiring a write-
> # lock on a given object x implies write locks on all
> objects associated
> # to x. If set to READ implicit read-locks are
> acquired.
> # Acquiring a read-lock on x thus allways results in
> implicit read-locks
> # on all associated objects.
> #LockAssociations=READ
> LockAssociations=WRITE
> #
> #
> #----------------------------------------------------------------------------------------
> # OQL / SQL settings
> #----------------------------------------------------------------------------------------
> # The OqlCollectionClass entry defines the collection
> type returned
> # from OQL queries. By default this value is set to
> DListImpl.
> # This will be good for most situations as DList
> allows maximum flexibility
> # in a ODMG environment. See also section 'ODMG
> settings'.
> # Using DLists for large resultsets may be bad for
> application performance.
> # For these scenarios you can use ArrayLists or
> Vectors.
> # Important note: the collections class to be used
> MUST implement the
> # interface
> org.apache.ojb.broker.ManageableCollection.
> #
> OqlCollectionClass=org.apache.ojb.odmg.collections.DListImpl_2
> #
> OqlCollectionClass=org.apache.ojb.broker.util.collections.ManageableArrayList
> #
> OqlCollectionClass=org.apache.ojb.broker.util.ManageableVector
> #
> # The SqlInLimit entry limits the number of values in
> IN-sql statement,
> # -1 for no limits. This hint is used in Criteria.
> SqlInLimit=200
> #
> #
> #----------------------------------------------------------------------------------------
> # ODMG settings
> #----------------------------------------------------------------------------------------
> # Specify the used base class for ODMG API
> # - ImplementationDefaultImpl is the default class
> # - ImplementationJTAImpl is for use in managed
> environments like J2EE conform
> # Application Server
> #
> #ImplementationClass=org.apache.ojb.odmg.ImplementationDefaultImpl
> ImplementationClass=org.apache.ojb.odmg.ImplementationJTAImpl
> #
> #
> # Specify the used tx handling.
> # - LocalTxManager use if you want the transaction to
> be associated by a thread
> # - JTATxManager use if you want the transaction to be
> associated via the Transaction
> # manager that is in your application server.
> #
> #OJBTxManagerClass=org.apache.ojb.odmg.LocalTxManager
> OJBTxManagerClass=org.apache.ojb.odmg.JTATxManager
> #
> #
> # Used ODMG collection implementation classes
> # (e.g. when do a Implementation#newDlist() call)
> #
> # org.odmg.DList implementation class
> DListClass=org.apache.ojb.odmg.collections.DListImpl_2
> #DListClass=org.apache.ojb.odmg.collections.DListImpl
> #
> # org.odmg.DArray implementation class
> DArrayClass=org.apache.ojb.odmg.collections.DListImpl_2
> #DArrayClass=org.apache.ojb.odmg.collections.DListImpl
> #
> # org.odmg.DMap implementation class
> DMapClass=org.apache.ojb.odmg.collections.DMapImpl
> #
> # org.odmg.DBag implementation class
> DBagClass=org.apache.ojb.odmg.collections.DBagImpl
> #
> # org.odmg.DSet implementation class
> DSetClass=org.apache.ojb.odmg.collections.DSetImpl
> #
> #
> #----------------------------------------------------------------------------------------
> # Meta data / mapping settings
> #----------------------------------------------------------------------------------------
> # The PersistentFieldClass property defines the
> implementation class
> # for PersistentField attributes used in the OJB
> MetaData layer.
> # By default the best performing attribute/refection
> based implementation
> # is selected (PersistentFieldDirectAccessImpl).
> #
> # - PersistentFieldDirectAccessImpl
> #   is a high-speed version of the access strategies.
> #   It does not cooperate with an AccessController,
> #   but accesses the fields directly. Persistent
> #   attributes don't need getters and setters
> #   and don't have to be declared public or protected
> # - PersistentFieldPrivilegedImpl
> #   Same as above, but does cooperate with
> AccessController and do not
> #   suppress the java language access check.
> # - PersistentFieldIntrospectorImpl
> #   uses JavaBeans compliant calls only to access
> persistent attributes.
> #   No Reflection is needed. But for each attribute
> xxx there must be
> #   public getXxx() and setXxx() methods.
> # - PersistentFieldDynaBeanAccessImpl
> #   implementation used to access a property from a
> #   org.apache.commons.beanutils.DynaBean.
> # - PersistentFieldAutoProxyImpl
> #   for each field determines upon first access how to
> access this particular field
> #   (directly, as a bean, as a dyna bean) and then
> uses that strategy
> #
> PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDirectAccessImpl
> #PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldPrivilegedImpl
> #PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldIntrospectorImpl
> #PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDynaBeanAccessImpl
> #PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldAutoProxyImpl
> #
> #
> #----------------------------------------------------------------------------------------
> # Component Intercepting for Profiling and Tracing
> #----------------------------------------------------------------------------------------
> # By enabling an InterceptorClass all OJB components
> will use
> # this Interceptor. Interceptors allow advanced
> tracing and Profiling
> # of all component method calls.
> # This is currently an experimental feature useful
> only for OJB kernel developers.
> #
> #InterceptorClass=org.apache.ojb.broker.util.interceptor.TracingInterceptor
> #
> #----------------------------------------------------------------------------------------
> # Transaction Management and assocation
> #----------------------------------------------------------------------------------------
> # (optional, only used when OJB runs within managed
> environments)
> # To praticipate in JTA transaction OJB needs access
> to the underlying transaction manager.
> # The TransactionManager is acquired in different ways
> dependent on the application server.
> # The JTATransactionManagerClass property allows you
> to specify the class that implements
> # the proper behaviour for finding the transaction
> manager. Only use when OJBTxManagerClass
> # is set to a factory that uses the application server
> transaction manager
> # (org.apache.ojb.odmg.JTATxManager)
> #
> # JBoss Transaction Manager Factory
> #JTATransactionManagerClass=org.apache.ojb.broker.transaction.tm.JBossTransactionManagerFactory
> # Weblogic Transaction Manager Factory
> #JTATransactionManagerClass=org.apache.ojb.broker.transaction.tm.WeblogicTransactionManagerFactory
> # WebSphere transaction manager factory
> #JTATransactionManagerClass=org.apache.ojb.broker.transaction.tm.WebSphereTransactionManagerFactory
> # Orion transaction manager factory
> JTATransactionManagerClass=org.apache.ojb.broker.transaction.tm.OrionTransactionManagerFactory
> # SunOne transaction manager factory
> #JTATransactionManagerClass=org.apache.ojb.broker.transaction.tm.SunOneTransactionManagerFactory
> # JOnAs transaction manager factory
> #JTATransactionManagerClass=org.apache.ojb.broker.transaction.tm.JOnASTransactionManagerFactory
> #
> #
> #----------------------------------------------------------------------------------------
> # Logging
> #----------------------------------------------------------------------------------------
> # The LoggerClass entry tells OJB which concrete
> Logger
> # implementation is to be used.
> #
> # Commons-logging
> #LoggerClass=org.apache.ojb.broker.util.logging.CommonsLoggerImpl
> # log4j based logging
> LoggerClass=org.apache.ojb.broker.util.logging.Log4jLoggerImpl
> # OJB's own simple looging support
> #LoggerClass=org.apache.ojb.broker.util.logging.PoorMansLoggerImpl
> LoggerConfigFile=log4j.properties
> #
> # The LogLevel entries tells OJB which LogLevels are
> active
> # for the different loggers used within OJB
> # Loglevels: DEBUG < INFO < WARN < ERROR < FATAL
> # That is loglevel WARN won't log DEBUG and INFO
> messages,
> # but will log WARN, ERROR, and FATAL messages
> #
> # Global default log level used for all logging
> # entities if not specified
> ROOT.LogLevel=DEBUG
> #
> # The Default Logger instance used within OJB
> DEFAULT.LogLevel=DEBUG
> # Logger for PersistenceBrokerImpl class
> org.apache.ojb.broker.core.PersistenceBrokerImpl.LogLevel=DEBUG
> # Logger for PersistenceBrokerFactory class
> PersistenceBrokerFactoryDefaultImpl
> org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl.LogLevel=DEBUG
> # Logger for RepositoryXmlHandler, useful for
> debugging parsing of repository.xml!
> # persistence capable object metadata
> org.apache.ojb.broker.metadata.RepositoryXmlHandler.LogLevel=DEBUG
> # Logger for ConnectionDescriptorXmlHandler, useful
> for debugging parsing of repository.xml!
> # connection specific metadata
> org.apache.ojb.broker.metadata.ConnectionDescriptorXmlHandler.LogLevel=DEBUG
> # Logger for JdbcAccess, useful for debugging JDBC
> related problems
> org.apache.ojb.broker.accesslayer.JdbcAccessImpl.LogLevel=DEBUG
> # Logger for RsIterator, useful for debugging problems
> with Object materialization
> org.apache.ojb.broker.accesslayer.RsIterator.LogLevel=DEBUG
> # Logger for StatementsForClass, useful for debugging
> JDBC Connection related problems
> org.apache.ojb.broker.accesslayer.StatementsForClassImpl.LogLevel=DEBUG
> # Logger for SqlGenerator, useful for debugging
> generation of SQL
> org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel=DEBUG
> # Logger for RepositoryPersistor
> org.apache.ojb.broker.metadata.RepositoryPersistor.LogLevel=DEBUG
> # Logger for ConnectionFactory base class
> org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.LogLevel=DEBUG
> # Logger for ConnectionManager
> org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.LogLevel=DEBUG
> # Logger for IndirectionHandler class
> org.apache.ojb.broker.core.proxy.IndirectionHandler.LogLevel=DEBUG
> #
> # Special Logger categories used in test suite and
> tutorials
> #
> # Logger for the ODMG Implementation
> ODMG.LogLevel=DEBUG
> # Logger for the JDO RI Implementation
> JDO.LogLevel=DEBUG
> # Logger for the performance tests
> performance.LogLevel=DEBUG
> # Logger for the soda api
> soda.LogLevel=DEBUG
> # Logger for the factory service
> ConfigurableFactory.LogLevel=DEBUG
> #
> #
> #----------------------------------------------------------------------------------------
> # End of OJB.properties file
> #----------------------------------------------------------------------------------------
> 
> 
> 
> 	
> 
> 	
> 		
> ____________________________________________________________
> Yahoo! Companion - Scarica gratis la toolbar di Ricerca di Yahoo! 
> http://companion.yahoo.it
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
> 
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org