Re: Help needed for Transaction Rollbacks
Hi Armin,
Again, I am really thankful to you for clearing that up. I followed both
the managed and non-managed approaches and both worked.
For the non-managed scenario, I set the settings as such:
useAutoCommit="2"
PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl
ConnectionFactoryClass=ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl
And the code looks as follows:
try {
broker.beginTransaction();
broker.store(objA);
broker.store(objB);
broker.deleteByQuery(someQuery);
broker.store(objC);
broker.commitTransaction();
} catch (Exception e) {
broker.abortTransaction();
}
For the managed scneario, I set the settings as such:
useAutoCommit="0"
PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactorySyncImpl
ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryManagedImpl
And the code looks as follows(I am using WSAD 5.1.2):
javax.transaction.UserTransaction userTx = null;
try {
InitialContext initCtx = new InitialContext();
userTx = (UserTransaction)initCtx.lookup("java:comp/UserTransaction");
userTx.begin();
broker.store(objA);
broker.store(objB);
broker.deleteByQuery(someQuery);
broker.store(objC);
userTx.commit();
} catch(Exception e) {
userTx.rollback();
}
Both of the above approaches worked. Now I would like to know which of
them is the better approach? What are the pros and cons of managed vs.
non-managed? Is there a document I can refer to?
Again, thank you very much for your help.
Regards,
-Vamsi
--- Armin Waibel <[EMAIL PROTECTED]> wrote:
> Hi Vamsi,
>
> > Is there something I should change in OJB.properties? I am using
> ojb1.0.1.
>
> Seems you mixed the managed and non-managed settings.
>
> managed:
> useAutoCommit="0"
>
PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactorySyncImpl
>
ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryManagedImpl
>
> non-managed:
> useAutoCommit="1" or "2"
>
PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl
> ConnectionFactoryClass= all except ConnectionFactoryManagedImpl
>
> Your example source seems to expect a non-managed environment, because
> you use the PB-tx demarcation.
> In managed environments you have to use programmatic transactions via
> JTA UserTransaction or declarative transaction e.g. via session beans
> and deployment descriptor entries (PB-tx declaration is not allowed).
>
> regards,
> Armin
>
>
>
> Vamsi Atluri wrote:
> > Hi Armin,
> >
> > I really appreciate your response. The connection descriptor is as
> > follows:
> >
> > > jcd-alias="OJBDb"
> > default-connection="true"
> > platform="Db2"
> > jdbc-level="1.0"
> > jndi-datasource-name="jdbc/ojbDataSource"
> > username="someUserName"
> > password="somePassWord"
> > batch-mode="false"
> > useAutoCommit="0"
> > ignoreAutoCommitExceptions="false">
> > >
>
className="org.apache.ojb.broker.util.sequence.SequenceManagerNativeImpl">
> > > attribute-value="1">
> >
> >
> >
> > The OJB.properties file has the following settings:
> >
> > # repository file settings
> > repositoryFile=repository.xml
> > useSerializedRepository=false
> > serializedRepositoryPath=.
> >
> > # PersistenceBrokerFactory / PersistenceBroker
> >
>
PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl
> >
> PersistenceBrokerClass=org.apache.ojb.broker.core.PersistenceBrokerImpl
> >
> > # PersistenceBroker pool
> > maxActive=100
> > maxIdle=-1
> > maxWait=2000
> > timeBetweenEvictionRunsMillis=-1
> > minEvictableIdleTimeMillis=100
> > whenExhaustedAction=2
> >
> > # ConnectionFactory / Default ConnectionPool
> >
>
ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryManagedImpl
> >
> > # ConnectionManager
> >
>
ConnectionManagerClass=org.apache.ojb.broker.accesslayer.ConnectionManagerImpl
> >
> > # SqlGenerator
> >
>
SqlGeneratorClass=org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl
> >
> > # IndirectionHandler
> >
>
IndirectionHandlerClass=org.apache.ojb.broker.core.proxy.IndirectionHandlerDefaultImpl
> >
> > # ListProxy
> > ListProxyClass=org.apache.ojb.broker.core.proxy.ListProxyDefaultImpl
> >
> > # SetProxy
> > SetProxyClass=org.apache.ojb.broker.core.proxy.SetProxyDefaultImpl
> >
> > # CollectionProxy
> >
>
CollectionProxyClass=org.apache.ojb.broker.core.proxy.CollectionProxyDefaultImpl
> >
> > # StatementManager
> >
> StatementManagerClass=org.apache.ojb.broker.accesslayer.StatementManager
> >
> > # StatementsForClass
> >
>
StatementsForClassClass=org.a
Expected Extent Behavior?
I have an Interface "I" It has implementing classes A, B, and C Classes B and C both extend class A and have a super reference to it. If use the following: when I search via getCollectionByQuery for instances of "I" then I get back instances of B and C with all their data and no A objects that duplicate the id's of these objects. (all instances of A are really either B or C, so this is what I want anyway) Previously (OJB1.01 and less) I seem to recall getting back both an A and a B or and A and a C object for each id when I attempted queries of this sort. If instead I use: then I get null values for all the A class fields in the returned class B and C objects. Is this the expected behavior? Should the query be extent aware like this? I just thought I'd ask for clarification and if this was odd behavior point it out. thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Help needed for Transaction Rollbacks
Hi Vamsi, > Is there something I should change in OJB.properties? I am using ojb1.0.1. Seems you mixed the managed and non-managed settings. managed: useAutoCommit="0" PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactorySyncImpl ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryManagedImpl non-managed: useAutoCommit="1" or "2" PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl ConnectionFactoryClass= all except ConnectionFactoryManagedImpl Your example source seems to expect a non-managed environment, because you use the PB-tx demarcation. In managed environments you have to use programmatic transactions via JTA UserTransaction or declarative transaction e.g. via session beans and deployment descriptor entries (PB-tx declaration is not allowed). regards, Armin Vamsi Atluri wrote: Hi Armin, I really appreciate your response. The connection descriptor is as follows: jcd-alias="OJBDb" default-connection="true" platform="Db2" jdbc-level="1.0" jndi-datasource-name="jdbc/ojbDataSource" username="someUserName" password="somePassWord" batch-mode="false" useAutoCommit="0" ignoreAutoCommitExceptions="false"> The OJB.properties file has the following settings: # repository file settings repositoryFile=repository.xml useSerializedRepository=false serializedRepositoryPath=. # PersistenceBrokerFactory / PersistenceBroker PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl PersistenceBrokerClass=org.apache.ojb.broker.core.PersistenceBrokerImpl # PersistenceBroker pool maxActive=100 maxIdle=-1 maxWait=2000 timeBetweenEvictionRunsMillis=-1 minEvictableIdleTimeMillis=100 whenExhaustedAction=2 # ConnectionFactory / Default ConnectionPool ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryManagedImpl # ConnectionManager ConnectionManagerClass=org.apache.ojb.broker.accesslayer.ConnectionManagerImpl # SqlGenerator SqlGeneratorClass=org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl # IndirectionHandler IndirectionHandlerClass=org.apache.ojb.broker.core.proxy.IndirectionHandlerDefaultImpl # ListProxy ListProxyClass=org.apache.ojb.broker.core.proxy.ListProxyDefaultImpl # SetProxy SetProxyClass=org.apache.ojb.broker.core.proxy.SetProxyDefaultImpl # CollectionProxy CollectionProxyClass=org.apache.ojb.broker.core.proxy.CollectionProxyDefaultImpl # StatementManager StatementManagerClass=org.apache.ojb.broker.accesslayer.StatementManager # StatementsForClass StatementsForClassClass=org.apache.ojb.broker.accesslayer.StatementsForClassImpl # JdbcAccess JdbcAccessClass=org.apache.ojb.broker.accesslayer.JdbcAccessImpl # Object cache ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheDefaultImpl descriptorBasedCaches=false # Locking LockManagerClass=org.apache.ojb.odmg.locking.LockManagerDefaultImpl LockMapClass=org.apache.ojb.odmg.locking.InMemoryLockMapImpl LockTimeout=6 ImplicitLocking=true LockServletUrl=http://127.0.0.1:8080/ojb-lockserver LockAssociations=WRITE # OQL / SQL settings OqlCollectionClass=org.apache.ojb.odmg.collections.DListImpl_2 SqlInLimit=200 # ODMG settings ImplementationClass=org.apache.ojb.odmg.ImplementationDefaultImpl OJBTxManagerClass=org.apache.ojb.odmg.LocalTxManager DListClass=org.apache.ojb.odmg.collections.DListImpl_2 DArrayClass=org.apache.ojb.odmg.collections.DListImpl_2 DMapClass=org.apache.ojb.odmg.collections.DMapImpl DBagClass=org.apache.ojb.odmg.collections.DBagImpl DSetClass=org.apache.ojb.odmg.collections.DSetImpl # Meta data / mapping settings PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDirectAccessImpl # Transaction Management and assocation JTATransactionManagerClass=org.apache.ojb.broker.transaction.tm.WebSphereTransactionManagerFactory # Logging LoggerClass=org.apache.ojb.broker.util.logging.PoorMansLoggerImpl LoggerConfigFile=log4j.properties DEFAULT.LogLevel=WARN org.apache.ojb.broker.core.PersistenceBrokerImpl.LogLevel=WARN org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl.LogLevel=WARN org.apache.ojb.broker.metadata.RepositoryXmlHandler.LogLevel=WARN org.apache.ojb.broker.metadata.ConnectionDescriptorXmlHandler.LogLevel=WARN org.apache.ojb.broker.accesslayer.JdbcAccessImpl.LogLevel=WARN org.apache.ojb.broker.accesslayer.RsIterator.LogLevel=WARN org.apache.ojb.broker.accesslayer.StatementsForClassImpl.LogLevel=WARN org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel=WARN org.apache.ojb.broker.metadata.RepositoryPersistor.LogLevel=WARN org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.LogLevel=WARN org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.LogLevel=WARN org.apache.ojb.broker.core.proxy.IndirectionHandler.LogLevel=WARN ODMG.LogLevel=DEBUG JDO.LogLevel=DEBUG performance.LogLevel=INFO soda.
Re: Help needed for Transaction Rollbacks
Hi Armin, I really appreciate your response. The connection descriptor is as follows: The OJB.properties file has the following settings: # repository file settings repositoryFile=repository.xml useSerializedRepository=false serializedRepositoryPath=. # PersistenceBrokerFactory / PersistenceBroker PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl PersistenceBrokerClass=org.apache.ojb.broker.core.PersistenceBrokerImpl # PersistenceBroker pool maxActive=100 maxIdle=-1 maxWait=2000 timeBetweenEvictionRunsMillis=-1 minEvictableIdleTimeMillis=100 whenExhaustedAction=2 # ConnectionFactory / Default ConnectionPool ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryManagedImpl # ConnectionManager ConnectionManagerClass=org.apache.ojb.broker.accesslayer.ConnectionManagerImpl # SqlGenerator SqlGeneratorClass=org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl # IndirectionHandler IndirectionHandlerClass=org.apache.ojb.broker.core.proxy.IndirectionHandlerDefaultImpl # ListProxy ListProxyClass=org.apache.ojb.broker.core.proxy.ListProxyDefaultImpl # SetProxy SetProxyClass=org.apache.ojb.broker.core.proxy.SetProxyDefaultImpl # CollectionProxy CollectionProxyClass=org.apache.ojb.broker.core.proxy.CollectionProxyDefaultImpl # StatementManager StatementManagerClass=org.apache.ojb.broker.accesslayer.StatementManager # StatementsForClass StatementsForClassClass=org.apache.ojb.broker.accesslayer.StatementsForClassImpl # JdbcAccess JdbcAccessClass=org.apache.ojb.broker.accesslayer.JdbcAccessImpl # Object cache ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheDefaultImpl descriptorBasedCaches=false # Locking LockManagerClass=org.apache.ojb.odmg.locking.LockManagerDefaultImpl LockMapClass=org.apache.ojb.odmg.locking.InMemoryLockMapImpl LockTimeout=6 ImplicitLocking=true LockServletUrl=http://127.0.0.1:8080/ojb-lockserver LockAssociations=WRITE # OQL / SQL settings OqlCollectionClass=org.apache.ojb.odmg.collections.DListImpl_2 SqlInLimit=200 # ODMG settings ImplementationClass=org.apache.ojb.odmg.ImplementationDefaultImpl OJBTxManagerClass=org.apache.ojb.odmg.LocalTxManager DListClass=org.apache.ojb.odmg.collections.DListImpl_2 DArrayClass=org.apache.ojb.odmg.collections.DListImpl_2 DMapClass=org.apache.ojb.odmg.collections.DMapImpl DBagClass=org.apache.ojb.odmg.collections.DBagImpl DSetClass=org.apache.ojb.odmg.collections.DSetImpl # Meta data / mapping settings PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDirectAccessImpl # Transaction Management and assocation JTATransactionManagerClass=org.apache.ojb.broker.transaction.tm.WebSphereTransactionManagerFactory # Logging LoggerClass=org.apache.ojb.broker.util.logging.PoorMansLoggerImpl LoggerConfigFile=log4j.properties DEFAULT.LogLevel=WARN org.apache.ojb.broker.core.PersistenceBrokerImpl.LogLevel=WARN org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl.LogLevel=WARN org.apache.ojb.broker.metadata.RepositoryXmlHandler.LogLevel=WARN org.apache.ojb.broker.metadata.ConnectionDescriptorXmlHandler.LogLevel=WARN org.apache.ojb.broker.accesslayer.JdbcAccessImpl.LogLevel=WARN org.apache.ojb.broker.accesslayer.RsIterator.LogLevel=WARN org.apache.ojb.broker.accesslayer.StatementsForClassImpl.LogLevel=WARN org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel=WARN org.apache.ojb.broker.metadata.RepositoryPersistor.LogLevel=WARN org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.LogLevel=WARN org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.LogLevel=WARN org.apache.ojb.broker.core.proxy.IndirectionHandler.LogLevel=WARN ODMG.LogLevel=DEBUG JDO.LogLevel=DEBUG performance.LogLevel=INFO soda.LogLevel=WARN ConfigurableFactory.LogLevel=WARN Is there something I should change in OJB.properties? I am using ojb1.0.1. Any help is appreciated. Thanks. Regards, -Vamsi --- Armin Waibel <[EMAIL PROTECTED]> wrote: > Hi Vamsi, > > Vamsi Atluri wrote: > > Hello all, > > > > I am having problem with getting my transactions rolled back. I have > read > > the documentation a bit about OTM but I am not clear about what I > should > > do in my situation. > > > > I am using OJB1.0.1 for DB2 and running on WAS 5.0 (currently testing > on > > WSAD 5.1.2). My data save code looks something like this: > > > > You have two possibilities: > > 1. Using OJB in non-managed environments (without delegating transaction > > handling to JTA - provided by WSAD). Use of the default > PersistenceBrokerFactoryClass (OJB.properties). > > 2. In managed environments by synchronize OJB within JTA-transactions. > Use of a specific PersistenceBrokerFactoryClass (see OJB.properties and > http://db.apache.org/ojb/docu/guides/deployment.html#Deployment+in+managed+environment+%28e.g.+EJB+based%29). > > > > PersistenceBroker broker = > > PersistenceBrokerFactory.
Re: Oracle 10g compliance
I've a OJB 1.0.3 running either Oracle 10 XE and SQL 2005 Express without changin a line of code... OJB rocks! Richter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Oracle 10g compliance
I am not running 1.0.4, heck I just inherit this code I am working with now, and they had renamed the jar file to just say ojb.jar but I know its not 1.0.4 (file data on jar is early March 2005). Everything seems stable so far, been running our junit tasks and building against our Oracle database. Wish I could tell you more, but the product we designed was switch to a SQL Server production install and we have been off Oracle for a couple of months now. -Original Message- From: Bruno CROS [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 21, 2006 1:12 AM To: OJB Users List Subject: Oracle 10g compliance Hi all, Apparently, 1.0.4 does not support Oracle 10g platform (torque does but not the OJB runtime) So, i go on with oracle 9i settings. Does anyone report experience (good or bad) of that ? Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
null super references with odmg?
I have an Interface "Substance" with multiple extent classes including "ProductSubstance." All the extent classes of "Substance" extend the "SubstanceBean" class and have a super reference to it. Recently I switched from using a striaght PB query for collections of "Substance" interface objects to using a PB inside of an ODMG transaction for the same thing. The query had worked priviously, but now I get null values for all the super fields. During execution I get the following: 1382710 DEBUG [http-8080-Processor23] metadata.SuperReferenceDescriptor$SuperReferenceField - Copy fields from source object 'org.aspca.substance.ProductSubstanceBean' using source fields declared in 'org.aspca.substance.SubstanceBean' to target object 'org.aspca.substance.ProductSubstanceBean' using target fields declared in 'org.aspca.substance.SubstanceBean' the fields to copy are declared in 'org.aspca.substance.SubstanceBean' class the used classes are associated by java inheritance: true ...and then later during the same query... 1383351 DEBUG [http-8080-Processor23] metadata.SuperReferenceDescriptor$SuperReferenceField - Copy fields from source object 'null' using source fields declared in 'org.aspca.substance.SubstanceBean' to target object 'org.aspca.substance.ProductSubstanceBean' using target fields declared in 'org.aspca.substance.SubstanceBean' the fields to copy are declared in 'org.aspca.substance.SubstanceBean' class the used classes are associated by java inheritance: true The first superreference seems to be copying from a productsubstance to a productsubstance using fields from substancebean and the second seems to be copying fields from a null substancebean object. In any case, I always end up with null values for all super fields including the PK field, but I get real values for all the child fields (except the PK/FK). Any idea what causes this? If more detailed code/repository information would be helpful I can supply it. thanks for any help - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Help needed for Transaction Rollbacks
Hi Vamsi,
Vamsi Atluri wrote:
Hello all,
I am having problem with getting my transactions rolled back. I have read
the documentation a bit about OTM but I am not clear about what I should
do in my situation.
I am using OJB1.0.1 for DB2 and running on WAS 5.0 (currently testing on
WSAD 5.1.2). My data save code looks something like this:
You have two possibilities:
1. Using OJB in non-managed environments (without delegating transaction
handling to JTA - provided by WSAD). Use of the default
PersistenceBrokerFactoryClass (OJB.properties).
2. In managed environments by synchronize OJB within JTA-transactions.
Use of a specific PersistenceBrokerFactoryClass (see OJB.properties and
http://db.apache.org/ojb/docu/guides/deployment.html#Deployment+in+managed+environment+%28e.g.+EJB+based%29).
PersistenceBroker broker =
PersistenceBrokerFactory.defaultPersistenceBroker();
try {
broker.beginTransaction();
broker.store(objA); //step 1
broker.store(objB); //step 2
broker.store(objC); //step 3
broker.deleteByQuery(someQuery); //step 4
broker.store(objD); //step 5
broker.commitTransaction();
} catch(PersistenceBrokerException pbe) {
if(null != broker) {
broker.abortTransaction();
}
} catch(Exception e) {
if(null != broker) {
broker.abortTransaction();
}
} finally {
if(null != broker) {
broker.close();
}
}
It so happens that if there is any Exception during any of the steps, the
previous steps are not being rolled back. Is it possible that I can get
the ConnectionManager from the broker and use it for managing my
transactions? The document says that OJB provides only DB level
transactions but not object level transactions. What does that this
exactly mean?
The PB-api (currently) only offer "DB level transactions"
http://db.apache.org/ojb/docu/guides/pb-guide.html#Transactions
This mean that the PB-api does not use a "unit-of work" concept when
starting a tx. All object manipulation is immediately written to the DB
and rollback when commit fail.
The ODMG-api use a kind of "unit-of-work" and write all modified objects
to DB as recently as tx.commit is called.
Do I "have" to implement OTM (which would be a huge
undertaking given the amount of tables we store)?
no
Your first example will work with the default settings shipped with OJB.
Assume you are using wrong configuration settings. Could you post
OJB.properties and jdbc-connection-descriptor settings?
You have to take care when using
> broker.deleteByQuery(someQuery); //step 4
because this call does bypass cache synchronization.
http://db.apache.org/ojb/api/org/apache/ojb/broker/PersistenceBroker.html#deleteByQuery(org.apache.ojb.broker.query.Query)
regards,
Armin
Or can I do something
like this:
PersistenceBroker broker =
PersistenceBrokerFactory.defaultPersistenceBroker();
java.sql.Connection conn = null;
try {
ConnectionManagerIF connectionManager =
broker.serviceConnectionManager();
conn = connectionManager.getConnection();
conn.setAutoCommit(false);
broker.store(objA); //step 1
broker.store(objB); //step 2
broker.store(objC); //step 3
broker.deleteByQuery(someQuery); //step 4
broker.store(objD); //step 5
conn.commit();
} catch(PersistenceBrokerException pbe) {
if(null != conn) {
conn.rollback();
}
} catch(Exception e) {
if(null != conn) {
conn.rollback();
}
} finally {
if(null != broker) {
broker.close();
}
}
Any help is greatly appreciated in this matter. Thank you.
Regards,
-Vamsi
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Want to taking note when PersistenceBroker storing M-N
Hi Josef, Josef Wagner wrote: Hello List, I want to log all data manipulations (update, delete, insert) from the PersistenceBroker in a separate log-table for synchronising client- width server-database. First, I have written an own PersistenceBroker (extended from PersistenceBrokerImpl) which overrides the store- and delete method's. Did you notice the OJB listener to track persistent object events: http://db.apache.org/ojb/docu/guides/pb-guide.html#Hook+into+OJB+-+PB-Listener+and+Instance+Callbacks http://db.apache.org/ojb/api/org/apache/ojb/broker/PBLifeCycleListener.html You can write your own PB implementation which add your tracking instance as permanent PBLifeCycleListener or without extend the PB by adding your tracking instance as temporary listener on each PB lookup. Now, I can log all exception the changes on M-N-tables. Can anyone tell me how I can get note of changes in m-n-tables. Well this is a problem, because the population of indirection tables of non-decomposed m:n relations are handled internally by OJB. The intern class used for handling m:n events is MtoNBroker.java. In theory you can extend this class too and use it in your PB implementation (disadvantage: internal classes can be changed often). regards, Armin Thanks a lot! Regards Josef Wagner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Misc questions
Hi Jean-Yves, Jean-Yves Sironneau wrote: Hello, I have a few unrelated questions regarding OJB : - Is there a way to set the deferrable foreign key constraint setting using OJB xdoclet module ? Assume no. But Tom have much more experience with xdoclet, so he can give you a professional answer. - When i use anonymous foreign key in a relationship, it's working perfectly for collections, but for simple reference to an object, i have to store the referenced object and then store the object referencing it, otherwise the two objects are created in db but the foreign key id is not set. I don't know about such an issue. But your question isn't detailed (auto-xxx settings, sample code, metadata mapping), so it's not possible to answer this. In generally anonymous FK should show same behavior as normal FK fields. It's pretty hard to discover it because, when i retrieve the objects they are ok even if the db foreign key is not set. It's just later, if i restart my application for example, that the referenced objects fields are null. So i have two questions : Do you think it's normal behaviour ? And how can i force OJB to retrieve everything from database to be able to test this kind of possible issues ? It would be helpful if you can provide a test (source + mapping) to reproduce the issue. By the way i'am using CVS version of OJB 1.1 approximately 2-3 months ago and the ODMG API (which is really working fine except for that). The 1.x trunk isn't for production environments - Is the code for OJB 1.1 located in the 1.0 SVN branch ? Because i don't know if i better use OJB 1.0.4 (or future 1.0.5) or the version i got from CVS. SVN trunk is OJB 1.x (early alpha state). The OJB_1_0_RELEASE branch is OJB 1.0.x (upcoming 1.0.5). So it's recommended to use 1.0.4 or the OJB_1_0_RELEASE branch (run the test suite to get an impression of current stability - this will show open issues). regards, Armin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Oracle 10g compliance
OK. Fine. I supposed that it was good. It was just to be sure. Thanks Thomas. On 2/21/06, Thomas Dudziak <[EMAIL PROTECTED]> wrote: > > On 2/21/06, Bruno CROS <[EMAIL PROTECTED]> wrote: > > > Apparently, 1.0.4 does not support Oracle 10g platform (torque does but > not > > the OJB runtime) > > > > So, i go on with oracle 9i settings. Does anyone report experience (good > or > > bad) of that ? > > OJB does work just fine with 10g. As far as OJB is concerned, there is > no relevant difference between 9i and 10g, so you should be fine with > the 9i platform. > > Tom > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Oracle 10g compliance
On 2/21/06, Bruno CROS <[EMAIL PROTECTED]> wrote: > Apparently, 1.0.4 does not support Oracle 10g platform (torque does but not > the OJB runtime) > > So, i go on with oracle 9i settings. Does anyone report experience (good or > bad) of that ? OJB does work just fine with 10g. As far as OJB is concerned, there is no relevant difference between 9i and 10g, so you should be fine with the 9i platform. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Oracle 10g compliance
Hi all, Apparently, 1.0.4 does not support Oracle 10g platform (torque does but not the OJB runtime) So, i go on with oracle 9i settings. Does anyone report experience (good or bad) of that ? Thanks.
