Re: null super references with odmg?
Hi Brian, if this issue isn't the same as in your later post "Expected Extent Behavior?" and does not mix different inheritance strategies (which is not supported), please provide a more detailed description so that I can implement a test case to reproduce the issue. regards, Armin Brian Latimer wrote: 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Expected Extent Behavior?
Hi Brian, Brian Latimer wrote: 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) This is the expected behavior. Take care not to mix different inheritance strategies (is not supported). This case (table-per-subclass inheritance + interface extent) should work. 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? In further OJB versions there was a bug related to the "table per subclass" inheritance (multiple joined tables bug) which only returns instances of the base class (see release-notes "known issues" section of previous versions). Think that the described behavior could be a side effect of this bug. regards, Armin 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Help needed for Transaction Rollbacks
> > I think OTM is kind of "deprecated", but i don't know if it's important > for > this issue. > In my mind when you do a commit a transaction, if something fails, no step > of the transaction should have been commited, so maybe your database > do not support transactions. > > I also wonder what the OTM story is. Is it because of the dirty reads? Does the 2nd level cache make the OTM obsolete?
Re: Help needed for Transaction Rollbacks
I think OTM is kind of "deprecated", but i don't know if it's important for
this issue.
In my mind when you do a commit a transaction, if something fails, no step
of the transaction should have been commited, so maybe your database
do not support transactions.
2006/2/21, Vamsi Atluri <[EMAIL PROTECTED]>:
>
> Hello all,
>
> I tested my own solution suggested below, but it still did not work. The
> class that I got for connection was :
>
> [EMAIL PROTECTED]
> wrapped [EMAIL PROTECTED]
> ]
>
> Why wouldn't straight commit() and rollback() not work on a Connection?
> Any help is greatly appreciated. Thank you.
>
> Regards,
> -Vamsi
>
> --- Vamsi Atluri <[EMAIL PROTECTED]> 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:
> >
> > 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? Do I "have" to implement OTM (which would be a huge
> > undertaking given the amount of tables we store)? 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: Misc questions
Thank you, Armin, I think i'am gonna try to use OJB 1.0.4, and if it does not work i'll post details about my issue. Jean-Yves 2006/2/21, Armin Waibel <[EMAIL PROTECTED]>: > > 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] > >
oc4j 9.0.4.0.1 : PersistenceBrokerException - java.lang.AbstractMethodError
Dear all, I am working on a j2ee web application using OJB (db-ojb-1.0.2) as persistence layer. The application server is oracle oc4j. The application is perfectly working on oc4j v9.0.3.0.0 and v9.0.4.0.0 (both enterprise and standalone versions). If I try to deploy the application on oc4j v9.0.4.0.0 O I get the following error as soon as I access a resource (not necessarily protected). I have no clue on what happens in this new version and if there is a OJB problem related to jdbc connection (here below the repository_database.xml used): Below is the error traced on my log files. Any help is really appreciated. Thanks. -- Transaction was rolled back: org.apache.ojb.broker.PersistenceBrokerException: java.lang.AbstractMethodError: com.evermind.sql.OrclCMTConnection.setStatementCacheSize(I)V; nested exception is: org.apache.ojb.broker.PersistenceBrokerException: java.lang.AbstractMethodError: com.evermind.sql.OrclCMTConnection.setStatementCacheSize(I)V com.evermind.server.rmi.OrionRemoteException: Transaction was rolled back: org.apache.ojb.broker.PersistenceBrokerException: java.lang.AbstractMethodError: com.evermind.sql.OrclCMTConnection.setStatementCacheSize(I)V at NoticeBoardController_StatelessSessionBeanWrapper14.getPublishedDemands(NoticeBoardController_StatelessSessionBeanWrapper14.java:3335) at xx..xxx.ejb.actions.noticeboard.GetPublishedDemandsEJBAction.perform(GetPublishedDemandsEJBAction.java:24) at xx..xxx.framework.j2ee.controller.ejb.StateMachine.processEvent(StateMachine.java:99) at xx..xxx.framework.j2ee.controller.ejb.EJBControllerBean.processEvent(EJBControllerBean.java:54) at EjbController_StatefulSessionBeanWrapper12.processEvent(EjbController_StatefulSessionBeanWrapper12.java:409) at xx..xxx.web.WebController.handleEvent(WebController.java:57) at xx..xxx.framework.j2ee.controller.web.RequestProcessor.processRequest(RequestProcessor.java:114) at xx..xxx.framework.j2ee.controller.web.MainController.processRequest(MainController.java:117) at xx..xxx.framework.j2ee.controller.web.MainController.doGet(MainController.java:245) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at com.evermind.server.http.ResourceFilterChain.doFilter(ResourceFilterChain.java:65) at xx..xxx.web.LoginFilter.doFilter(LoginFilter.java:142) at com.evermind.server.http.EvermindFilterChain.doFilter(EvermindFilterChain.java:16) at xx..xxx.web.LoginFilter.doFilter(LoginFilter.java:142) at com.evermind.server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:600) at com.evermind.server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:317) at com.evermind.server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:790) at com.evermind.server.http.HttpRequestHandler.run(HttpRequestHandler.java:270) at com.evermind.server.http.HttpRequestHandler.run(HttpRequestHandler.java:112) at com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:192) at java.lang.Thread.run(Thread.java:534) Nested exception is: org.apache.ojb.broker.PersistenceBrokerException: java.lang.AbstractMethodError: com.evermind.sql.OrclCMTConnection.setStatementCacheSize(I)V at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryReferenceBroker.java:259) at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryReferenceBroker.java:271) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(PersistenceBrokerImpl.java:1367) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery(DelegatingPersistenceBroker.java:338) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery(DelegatingPersistenceBroker.java:338) at xx..xxx.ojb.manager.NoticeBoardManager.getPublishedDemands(NoticeBoardManager.java:177) at xx..xxx.ejb.noticeboard.NoticeBoardControllerBean.getPublishedDemands(NoticeBoardControllerBean.java:618) at NoticeBoardController_StatelessSessionBeanWrapper14.getPublishedDemands(NoticeBoardController_StatelessSessionBeanWrapper14.java:3290) at xx..xxx.ejb.actions.noticeboard.GetPublishedDemandsEJBAction.perform(GetPublishedDemandsEJBAction.java:24) at xx..xxx.framework.j2ee.controller.ejb.StateMachine.processEvent(StateMachine.java:99) at xx..xxx.framework.j2ee.controller.ejb.EJBControllerBean.processEvent(EJBControllerBean.java:54) at EjbController_StatefulSessionBeanWrapper12.processEvent(EjbController_StatefulSessionBeanWrapper12.java:409) at xx..xxx.we
