AW: Support of database views
Hi Vasily, using the view as a table (following your recommendation) shows a strange behaviour. When a field in a table is updated and the matching object returns the correct new value the object related to the view (spanning two tables ) still holds the old value for a long time (minutes). Have you (or soneome else) ever had such a problem? Is there something I can configure (in ojb.properties)? I'm using OJB 1.0.3 with PB api. Frank -Ursprüngliche Nachricht- Von: Vasily Ivanov [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 12. September 2006 01:19 An: OJB Users List Betreff: Re: Support of database views Hi Frank, We used to work with views without any issue, just put view's name as table attribute in class-descriptor. However, you will only be able to read objects from that view. Regards, Vasily On 9/11/06, Hiller, Frank RD-AS2 [EMAIL PROTECTED] wrote: Short question: I couldn't find a functionality to deal with database views (create view...) within OJB. Is there a reason for that? Is the answer use ReportQuery. Thank you, Frank Confidentiality note: The information in this email and any attachment may contain confidential and proprietary information of Heidelberger Druckmaschinen AG and/or its affiliates and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any review, reliance or distribution by others or forwarding without express permission is strictly prohibited and may cause liability. In case you have received this message due to an error in transmission, we kindly ask you to notify the sender immediately and to delete this email and any attachment from your system. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Confidentiality note: The information in this email and any attachment may contain confidential and proprietary information of Heidelberger Druckmaschinen AG and/or its affiliates and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any review, reliance or distribution by others or forwarding without express permission is strictly prohibited and may cause liability. In case you have received this message due to an error in transmission, we kindly ask you to notify the sender immediately and to delete this email and any attachment from your system. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: removal aware list
As name said, it's a Removal Aware. If you don't wish objects removed, don't use RemovarAware. The default implementation is not RemovalAwareList, so it's sufficient to remove the specific implementation on mapping. IT: some older versions of OJB used RemovalAwareList as default - so, please, if you are not using 1.0.3 or 1.0.4, upgrade your version (check mail list about changes that could affect your upgrade). Regards, Richter Dennis Bekkering escreveu: Hello all, I have an M:N collection that has a ManageableArrayList as collection class and proxy set to true. But when the collection is materialized the underlying implementation becomes RemovalAwareList. When i remove items from that list the records are also deleted. I tried to find out how that can happen with the debugger but i cannot find out why. regards, Dennis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Result set closed! Help Urgent!
Hi, verify calling to pb.close, pb.commit transaction method : if you call pb.close or pb.commit transaction befor sending result of your query to your business layer you lost the result set. hope that help you. On 9/19/06, Vagula [EMAIL PROTECTED] wrote: Hi, I'm getting the following error when trying access a particular screen: org.apache.ojb.broker.PersistenceBrokerException: org.apache.ojb.broker.PersistenceBrokerSQLException: Calling ResultSet.next() failed at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(Unk nown Source) at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(Unk nown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Un known Source) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQu ery(Unknown Source) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQu ery(Unknown Source) at com.inetpsa.pac.service.common.IndividualSearchService.getResults(Indivi dualSearchService.java:132) at com.inetpsa.pac.service.common.SearchService.doExecute(SearchService.jav a:210) at com.inetpsa.fwk.service.BusinessService.execute(BusinessService.java:402 ) at com.inetpsa.pac.util.SearchList.getResults(SearchList.java:387) at com.inetpsa.pac.util.SearchList.loadPage(SearchList.java:474) at com.inetpsa.pac.util.SearchList.init(SearchList.java:134) at com.inetpsa.pac.ui.action.common.IndividualSearchAction.searchAffectatio n(IndividualSearchAction.java:413) at com.inetpsa.pac.ui.action.common.IndividualSearchAction.doExecute(Indivi dualSearchAction.java:189) at com.inetpsa.fwk.struts.action.FWKActionWrapper.doExecute(FWKActionWrappe r.java:118) at com.inetpsa.fwk.struts.action.FWKActionWrapper.execute(FWKActionWrapper. java:99) at com.inetpsa.fwk.struts.action.FWKAction.execute(FWKAction.java:90) at org.apache.struts.action.RequestProcessor.processActionPerform(RequestPr ocessor.java:484) at com.inetpsa.fwk.struts.action.FWKLayoutRequestProcessor.parentProcessAct ionPerform(FWKLayoutRequestProcessor.java:146) at com.inetpsa.fwk.struts.action.FWKRequestProcessorWrapper.processActionPe rform(FWKRequestProcessorWrapper.java:603) at com.inetpsa.fwk.struts.action.FWKLayoutRequestProcessor.processActionPer form(FWKLayoutRequestProcessor.java:68) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java: 274) at com.inetpsa.fwk.struts.action.FWKLayoutRequestProcessor.parentProcess(FW KLayoutRequestProcessor.java:121) at com.inetpsa.fwk.struts.action.FWKRequestProcessorWrapper.process(FWKRequ estProcessorWrapper.java:795) at com.inetpsa.fwk.struts.action.FWKLayoutRequestProcessor.process(FWKLayou tRequestProcessor.java:58) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525) at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at com.ibm.ws.webcontainer.servlet.StrictServletInstance.doService(StrictSe rvletInstance.java:110) at com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet._service(StrictLi fecycleServlet.java:174) at com.ibm.ws.webcontainer.servlet.IdleServletState.service(StrictLifecycle Servlet.java:313) at com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet.service(StrictLif ecycleServlet.java:116) at com.ibm.ws.webcontainer.servlet.ServletInstance.service(ServletInstance. java:292) at com.ibm.ws.webcontainer.servlet.ValidServletReferenceState.dispatch(Vali dServletReferenceState.java:42) at com.ibm.ws.webcontainer.servlet.ServletInstanceReference.dispatch(Servle tInstanceReference.java:47) at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterCh ain.java:76) at com.inetpsa.pac.arch.util.RequestEncodingFilter.doFilter(RequestEncoding Filter.java:72) at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInst anceWrapper.java:132) at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterCh ain.java:71) at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.handleWebAppDispa tch(WebAppRequestDispatcher.java:1078) at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.dispatch(WebAppRe questDispatcher.java:639) at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.forward(WebAppReq uestDispatcher.java:209) at com.ibm.ws.webcontainer.srt.WebAppInvoker.doForward(WebAppInvoker.java:1 27) at com.ibm.ws.webcontainer.srt.WebAppInvoker.handleInvocationHook(WebAppInv oker.java:286) at com.ibm.ws.webcontainer.cache.invocation.CachedInvocation.handleInvocati
AW: Support of database views
Additional information: When I explicitely remove the objects from the brokers internal cache (broker.removeFromCache(obj)) it works. Is it a bug? Frank -Ursprüngliche Nachricht- Von: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 19. September 2006 13:56 An: OJB Users List Betreff: AW: Support of database views Hi Vasily, using the view as a table (following your recommendation) shows a strange behaviour. When a field in a table is updated and the matching object returns the correct new value the object related to the view (spanning two tables ) still holds the old value for a long time (minutes). Have you (or soneome else) ever had such a problem? Is there something I can configure (in ojb.properties)? I'm using OJB 1.0.3 with PB api. Frank -Ursprüngliche Nachricht- Von: Vasily Ivanov [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 12. September 2006 01:19 An: OJB Users List Betreff: Re: Support of database views Hi Frank, We used to work with views without any issue, just put view's name as table attribute in class-descriptor. However, you will only be able to read objects from that view. Regards, Vasily On 9/11/06, Hiller, Frank RD-AS2 [EMAIL PROTECTED] wrote: Short question: I couldn't find a functionality to deal with database views (create view...) within OJB. Is there a reason for that? Is the answer use ReportQuery. Thank you, Frank Confidentiality note: The information in this email and any attachment may contain confidential and proprietary information of Heidelberger Druckmaschinen AG and/or its affiliates and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any review, reliance or distribution by others or forwarding without express permission is strictly prohibited and may cause liability. In case you have received this message due to an error in transmission, we kindly ask you to notify the sender immediately and to delete this email and any attachment from your system. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Confidentiality note: The information in this email and any attachment may contain confidential and proprietary information of Heidelberger Druckmaschinen AG and/or its affiliates and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any review, reliance or distribution by others or forwarding without express permission is strictly prohibited and may cause liability. In case you have received this message due to an error in transmission, we kindly ask you to notify the sender immediately and to delete this email and any attachment from your system. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Confidentiality note: The information in this email and any attachment may contain confidential and proprietary information of Heidelberger Druckmaschinen AG and/or its affiliates and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any review, reliance or distribution by others or forwarding without express permission is strictly prohibited and may cause liability. In case you have received this message due to an error in transmission, we kindly ask you to notify the sender immediately and to delete this email and any attachment from your system. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Support of database views
No, it's not really a bug; Let's say you have objects A, B and C where C is an objject mapped onto a view joining A B. OJB Caches objects on their Class + PK; when you update an object, it is ejected from the cache based on it's class and PK. So, let's say C with a PK of one is references A with a PK of 2 You read from C - C[1] is inserted in the cache You read A - A[2] is inserted in the cache You update A - A[2] is dropped from the cache but C[1] is still in the cache. OJB doesn't (and can't) know about the relationship between A C If all updates are done from OJB, and if you can derive the PK of C (in the above example) from A, then you could implement some kind of listener that says whenever A is updated, drop C from the cache You might also be able to specify that C should never be cached (by specifying the org.apache.ojb.broker.cache.ObjectCacheEmptyImpl in object-cache element for the class in the repostory.xml) Cheers, Charles. -Original Message- From: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] Sent: 19 September 2006 14:09 To: OJB Users List Subject: AW: Support of database views Additional information: When I explicitely remove the objects from the brokers internal cache (broker.removeFromCache(obj)) it works. Is it a bug? Frank -Ursprüngliche Nachricht- Von: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 19. September 2006 13:56 An: OJB Users List Betreff: AW: Support of database views Hi Vasily, using the view as a table (following your recommendation) shows a strange behaviour. When a field in a table is updated and the matching object returns the correct new value the object related to the view (spanning two tables ) still holds the old value for a long time (minutes). Have you (or soneome else) ever had such a problem? Is there something I can configure (in ojb.properties)? I'm using OJB 1.0.3 with PB api. Frank -Ursprüngliche Nachricht- Von: Vasily Ivanov [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 12. September 2006 01:19 An: OJB Users List Betreff: Re: Support of database views Hi Frank, We used to work with views without any issue, just put view's name as table attribute in class-descriptor. However, you will only be able to read objects from that view. Regards, Vasily On 9/11/06, Hiller, Frank RD-AS2 [EMAIL PROTECTED] wrote: Short question: I couldn't find a functionality to deal with database views (create view...) within OJB. Is there a reason for that? Is the answer use ReportQuery. Thank you, Frank Confidentiality note: The information in this email and any attachment may contain confidential and proprietary information of Heidelberger Druckmaschinen AG and/or its affiliates and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any review, reliance or distribution by others or forwarding without express permission is strictly prohibited and may cause liability. In case you have received this message due to an error in transmission, we kindly ask you to notify the sender immediately and to delete this email and any attachment from your system. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Confidentiality note: The information in this email and any attachment may contain confidential and proprietary information of Heidelberger Druckmaschinen AG and/or its affiliates and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any review, reliance or distribution by others or forwarding without express permission is strictly prohibited and may cause liability. In case you have received this message due to an error in transmission, we kindly ask you to notify the sender immediately and to delete this email and any attachment from your system. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Confidentiality note: The information in this email and any attachment may contain confidential and proprietary information of Heidelberger Druckmaschinen AG and/or its affiliates and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any review, reliance or distribution by others or forwarding without express permission is strictly prohibited and may cause liability. In case you have received this message due to an error in transmission, we kindly ask you to notify the sender immediately and to delete this email and any attachment from your system.
AW: Support of database views
I do not expect to automatically update the object in cache representing the view. After the update of A or B I explicitely read the view. At that point my expactation was to retrieve the new value. The SQL statement returns the correct (new) value, but ojb uses the object from the cache with the old value. This confuses me a little. Best regards, Frank -Ursprüngliche Nachricht- Von: Charles Anthony [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 19. September 2006 15:23 An: OJB Users List Betreff: RE: Support of database views No, it's not really a bug; Let's say you have objects A, B and C where C is an objject mapped onto a view joining A B. OJB Caches objects on their Class + PK; when you update an object, it is ejected from the cache based on it's class and PK. So, let's say C with a PK of one is references A with a PK of 2 You read from C - C[1] is inserted in the cache You read A - A[2] is inserted in the cache You update A - A[2] is dropped from the cache but C[1] is still in the cache. OJB doesn't (and can't) know about the relationship between A C If all updates are done from OJB, and if you can derive the PK of C (in the above example) from A, then you could implement some kind of listener that says whenever A is updated, drop C from the cache You might also be able to specify that C should never be cached (by specifying the org.apache.ojb.broker.cache.ObjectCacheEmptyImpl in object-cache element for the class in the repostory.xml) Cheers, Charles. -Original Message- From: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] Sent: 19 September 2006 14:09 To: OJB Users List Subject: AW: Support of database views Additional information: When I explicitely remove the objects from the brokers internal cache (broker.removeFromCache(obj)) it works. Is it a bug? Frank -Ursprüngliche Nachricht- Von: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 19. September 2006 13:56 An: OJB Users List Betreff: AW: Support of database views Hi Vasily, using the view as a table (following your recommendation) shows a strange behaviour. When a field in a table is updated and the matching object returns the correct new value the object related to the view (spanning two tables ) still holds the old value for a long time (minutes). Have you (or soneome else) ever had such a problem? Is there something I can configure (in ojb.properties)? I'm using OJB 1.0.3 with PB api. Frank -Ursprüngliche Nachricht- Von: Vasily Ivanov [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 12. September 2006 01:19 An: OJB Users List Betreff: Re: Support of database views Hi Frank, We used to work with views without any issue, just put view's name as table attribute in class-descriptor. However, you will only be able to read objects from that view. Regards, Vasily On 9/11/06, Hiller, Frank RD-AS2 [EMAIL PROTECTED] wrote: Short question: I couldn't find a functionality to deal with database views (create view...) within OJB. Is there a reason for that? Is the answer use ReportQuery. Thank you, Frank Confidentiality note: The information in this email and any attachment may contain confidential and proprietary information of Heidelberger Druckmaschinen AG and/or its affiliates and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any review, reliance or distribution by others or forwarding without express permission is strictly prohibited and may cause liability. In case you have received this message due to an error in transmission, we kindly ask you to notify the sender immediately and to delete this email and any attachment from your system. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Confidentiality note: The information in this email and any attachment may contain confidential and proprietary information of Heidelberger Druckmaschinen AG and/or its affiliates and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any review, reliance or distribution by others or forwarding without express permission is strictly prohibited and may cause liability. In case you have received this message due to an error in transmission, we kindly ask you to notify the sender immediately and to delete this email and any attachment from your system. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Confidentiality note: The information in this email and any attachment may contain confidential and proprietary information of Heidelberger Druckmaschinen AG
RE: Support of database views
Yes, but all (by default) all reads ARE transparently cached (to improve performance). So if you've read C, then you do an update of A or B, then you re-read C - you will not see the updates but the OLD version of C. It's a bit difficult to explain, and I'm obviously not being very clear. -Original Message- From: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] Sent: 19 September 2006 14:52 To: OJB Users List Subject: AW: Support of database views I do not expect to automatically update the object in cache representing the view. After the update of A or B I explicitely read the view. At that point my expactation was to retrieve the new value. The SQL statement returns the correct (new) value, but ojb uses the object from the cache with the old value. This confuses me a little. Best regards, Frank -Ursprüngliche Nachricht- Von: Charles Anthony [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 19. September 2006 15:23 An: OJB Users List Betreff: RE: Support of database views No, it's not really a bug; Let's say you have objects A, B and C where C is an objject mapped onto a view joining A B. OJB Caches objects on their Class + PK; when you update an object, it is ejected from the cache based on it's class and PK. So, let's say C with a PK of one is references A with a PK of 2 You read from C - C[1] is inserted in the cache You read A - A[2] is inserted in the cache You update A - A[2] is dropped from the cache but C[1] is still in the cache. OJB doesn't (and can't) know about the relationship between A C If all updates are done from OJB, and if you can derive the PK of C (in the above example) from A, then you could implement some kind of listener that says whenever A is updated, drop C from the cache You might also be able to specify that C should never be cached (by specifying the org.apache.ojb.broker.cache.ObjectCacheEmptyImpl in object-cache element for the class in the repostory.xml) Cheers, Charles. -Original Message- From: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] Sent: 19 September 2006 14:09 To: OJB Users List Subject: AW: Support of database views Additional information: When I explicitely remove the objects from the brokers internal cache (broker.removeFromCache(obj)) it works. Is it a bug? Frank -Ursprüngliche Nachricht- Von: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 19. September 2006 13:56 An: OJB Users List Betreff: AW: Support of database views Hi Vasily, using the view as a table (following your recommendation) shows a strange behaviour. When a field in a table is updated and the matching object returns the correct new value the object related to the view (spanning two tables ) still holds the old value for a long time (minutes). Have you (or soneome else) ever had such a problem? Is there something I can configure (in ojb.properties)? I'm using OJB 1.0.3 with PB api. Frank -Ursprüngliche Nachricht- Von: Vasily Ivanov [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 12. September 2006 01:19 An: OJB Users List Betreff: Re: Support of database views Hi Frank, We used to work with views without any issue, just put view's name as table attribute in class-descriptor. However, you will only be able to read objects from that view. Regards, Vasily On 9/11/06, Hiller, Frank RD-AS2 [EMAIL PROTECTED] wrote: Short question: I couldn't find a functionality to deal with database views (create view...) within OJB. Is there a reason for that? Is the answer use ReportQuery. Thank you, Frank Confidentiality note: The information in this email and any attachment may contain confidential and proprietary information of Heidelberger Druckmaschinen AG and/or its affiliates and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any review, reliance or distribution by others or forwarding without express permission is strictly prohibited and may cause liability. In case you have received this message due to an error in transmission, we kindly ask you to notify the sender immediately and to delete this email and any attachment from your system. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Confidentiality note: The information in this email and any attachment may contain confidential and proprietary information of Heidelberger Druckmaschinen AG and/or its affiliates and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any review, reliance or distribution by
AW: Support of database views
Ok, I see. Setting object-cache class=org.apache.ojb.broker.cache.ObjectCacheEmptyImpl/ on the specific table (that actually is a view) resolves the problem? Frank -Ursprüngliche Nachricht- Von: Charles Anthony [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 19. September 2006 16:04 An: OJB Users List Betreff: RE: Support of database views Yes, but all (by default) all reads ARE transparently cached (to improve performance). So if you've read C, then you do an update of A or B, then you re-read C - you will not see the updates but the OLD version of C. It's a bit difficult to explain, and I'm obviously not being very clear. -Original Message- From: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] Sent: 19 September 2006 14:52 To: OJB Users List Subject: AW: Support of database views I do not expect to automatically update the object in cache representing the view. After the update of A or B I explicitely read the view. At that point my expactation was to retrieve the new value. The SQL statement returns the correct (new) value, but ojb uses the object from the cache with the old value. This confuses me a little. Best regards, Frank -Ursprüngliche Nachricht- Von: Charles Anthony [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 19. September 2006 15:23 An: OJB Users List Betreff: RE: Support of database views No, it's not really a bug; Let's say you have objects A, B and C where C is an objject mapped onto a view joining A B. OJB Caches objects on their Class + PK; when you update an object, it is ejected from the cache based on it's class and PK. So, let's say C with a PK of one is references A with a PK of 2 You read from C - C[1] is inserted in the cache You read A - A[2] is inserted in the cache You update A - A[2] is dropped from the cache but C[1] is still in the cache. OJB doesn't (and can't) know about the relationship between A C If all updates are done from OJB, and if you can derive the PK of C (in the above example) from A, then you could implement some kind of listener that says whenever A is updated, drop C from the cache You might also be able to specify that C should never be cached (by specifying the org.apache.ojb.broker.cache.ObjectCacheEmptyImpl in object-cache element for the class in the repostory.xml) Cheers, Charles. -Original Message- From: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] Sent: 19 September 2006 14:09 To: OJB Users List Subject: AW: Support of database views Additional information: When I explicitely remove the objects from the brokers internal cache (broker.removeFromCache(obj)) it works. Is it a bug? Frank -Ursprüngliche Nachricht- Von: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 19. September 2006 13:56 An: OJB Users List Betreff: AW: Support of database views Hi Vasily, using the view as a table (following your recommendation) shows a strange behaviour. When a field in a table is updated and the matching object returns the correct new value the object related to the view (spanning two tables ) still holds the old value for a long time (minutes). Have you (or soneome else) ever had such a problem? Is there something I can configure (in ojb.properties)? I'm using OJB 1.0.3 with PB api. Frank -Ursprüngliche Nachricht- Von: Vasily Ivanov [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 12. September 2006 01:19 An: OJB Users List Betreff: Re: Support of database views Hi Frank, We used to work with views without any issue, just put view's name as table attribute in class-descriptor. However, you will only be able to read objects from that view. Regards, Vasily On 9/11/06, Hiller, Frank RD-AS2 [EMAIL PROTECTED] wrote: Short question: I couldn't find a functionality to deal with database views (create view...) within OJB. Is there a reason for that? Is the answer use ReportQuery. Thank you, Frank Confidentiality note: The information in this email and any attachment may contain confidential and proprietary information of Heidelberger Druckmaschinen AG and/or its affiliates and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any review, reliance or distribution by others or forwarding without express permission is strictly prohibited and may cause liability. In case you have received this message due to an error in transmission, we kindly ask you to notify the sender immediately and to delete this email and any attachment from your system. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Confidentiality note: The
RE: Support of database views
Well, that's my guess... -Original Message- From: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] Sent: 19 September 2006 15:08 To: OJB Users List Subject: AW: Support of database views Ok, I see. Setting object-cache class=org.apache.ojb.broker.cache.ObjectCacheEmptyImpl/ on the specific table (that actually is a view) resolves the problem? Frank -Ursprüngliche Nachricht- Von: Charles Anthony [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 19. September 2006 16:04 An: OJB Users List Betreff: RE: Support of database views Yes, but all (by default) all reads ARE transparently cached (to improve performance). So if you've read C, then you do an update of A or B, then you re-read C - you will not see the updates but the OLD version of C. It's a bit difficult to explain, and I'm obviously not being very clear. -Original Message- From: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] Sent: 19 September 2006 14:52 To: OJB Users List Subject: AW: Support of database views I do not expect to automatically update the object in cache representing the view. After the update of A or B I explicitely read the view. At that point my expactation was to retrieve the new value. The SQL statement returns the correct (new) value, but ojb uses the object from the cache with the old value. This confuses me a little. Best regards, Frank -Ursprüngliche Nachricht- Von: Charles Anthony [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 19. September 2006 15:23 An: OJB Users List Betreff: RE: Support of database views No, it's not really a bug; Let's say you have objects A, B and C where C is an objject mapped onto a view joining A B. OJB Caches objects on their Class + PK; when you update an object, it is ejected from the cache based on it's class and PK. So, let's say C with a PK of one is references A with a PK of 2 You read from C - C[1] is inserted in the cache You read A - A[2] is inserted in the cache You update A - A[2] is dropped from the cache but C[1] is still in the cache. OJB doesn't (and can't) know about the relationship between A C If all updates are done from OJB, and if you can derive the PK of C (in the above example) from A, then you could implement some kind of listener that says whenever A is updated, drop C from the cache You might also be able to specify that C should never be cached (by specifying the org.apache.ojb.broker.cache.ObjectCacheEmptyImpl in object-cache element for the class in the repostory.xml) Cheers, Charles. -Original Message- From: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] Sent: 19 September 2006 14:09 To: OJB Users List Subject: AW: Support of database views Additional information: When I explicitely remove the objects from the brokers internal cache (broker.removeFromCache(obj)) it works. Is it a bug? Frank -Ursprüngliche Nachricht- Von: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 19. September 2006 13:56 An: OJB Users List Betreff: AW: Support of database views Hi Vasily, using the view as a table (following your recommendation) shows a strange behaviour. When a field in a table is updated and the matching object returns the correct new value the object related to the view (spanning two tables ) still holds the old value for a long time (minutes). Have you (or soneome else) ever had such a problem? Is there something I can configure (in ojb.properties)? I'm using OJB 1.0.3 with PB api. Frank -Ursprüngliche Nachricht- Von: Vasily Ivanov [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 12. September 2006 01:19 An: OJB Users List Betreff: Re: Support of database views Hi Frank, We used to work with views without any issue, just put view's name as table attribute in class-descriptor. However, you will only be able to read objects from that view. Regards, Vasily On 9/11/06, Hiller, Frank RD-AS2 [EMAIL PROTECTED] wrote: Short question: I couldn't find a functionality to deal with database views (create view...) within OJB. Is there a reason for that? Is the answer use ReportQuery. Thank you, Frank Confidentiality note: The information in this email and any attachment may contain confidential and proprietary information of Heidelberger Druckmaschinen AG and/or its affiliates and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any review, reliance or distribution by others or forwarding without express permission is strictly prohibited and may cause liability. In case you have received this message due to an error
AW: Support of database views
Yes, it works. Thank youFrank -Ursprüngliche Nachricht- Von: Charles Anthony [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 19. September 2006 16:09 An: OJB Users List Betreff: RE: Support of database views Well, that's my guess... -Original Message- From: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] Sent: 19 September 2006 15:08 To: OJB Users List Subject: AW: Support of database views Ok, I see. Setting object-cache class=org.apache.ojb.broker.cache.ObjectCacheEmptyImpl/ on the specific table (that actually is a view) resolves the problem? Frank -Ursprüngliche Nachricht- Von: Charles Anthony [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 19. September 2006 16:04 An: OJB Users List Betreff: RE: Support of database views Yes, but all (by default) all reads ARE transparently cached (to improve performance). So if you've read C, then you do an update of A or B, then you re-read C - you will not see the updates but the OLD version of C. It's a bit difficult to explain, and I'm obviously not being very clear. -Original Message- From: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] Sent: 19 September 2006 14:52 To: OJB Users List Subject: AW: Support of database views I do not expect to automatically update the object in cache representing the view. After the update of A or B I explicitely read the view. At that point my expactation was to retrieve the new value. The SQL statement returns the correct (new) value, but ojb uses the object from the cache with the old value. This confuses me a little. Best regards, Frank -Ursprüngliche Nachricht- Von: Charles Anthony [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 19. September 2006 15:23 An: OJB Users List Betreff: RE: Support of database views No, it's not really a bug; Let's say you have objects A, B and C where C is an objject mapped onto a view joining A B. OJB Caches objects on their Class + PK; when you update an object, it is ejected from the cache based on it's class and PK. So, let's say C with a PK of one is references A with a PK of 2 You read from C - C[1] is inserted in the cache You read A - A[2] is inserted in the cache You update A - A[2] is dropped from the cache but C[1] is still in the cache. OJB doesn't (and can't) know about the relationship between A C If all updates are done from OJB, and if you can derive the PK of C (in the above example) from A, then you could implement some kind of listener that says whenever A is updated, drop C from the cache You might also be able to specify that C should never be cached (by specifying the org.apache.ojb.broker.cache.ObjectCacheEmptyImpl in object-cache element for the class in the repostory.xml) Cheers, Charles. -Original Message- From: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] Sent: 19 September 2006 14:09 To: OJB Users List Subject: AW: Support of database views Additional information: When I explicitely remove the objects from the brokers internal cache (broker.removeFromCache(obj)) it works. Is it a bug? Frank -Ursprüngliche Nachricht- Von: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 19. September 2006 13:56 An: OJB Users List Betreff: AW: Support of database views Hi Vasily, using the view as a table (following your recommendation) shows a strange behaviour. When a field in a table is updated and the matching object returns the correct new value the object related to the view (spanning two tables ) still holds the old value for a long time (minutes). Have you (or soneome else) ever had such a problem? Is there something I can configure (in ojb.properties)? I'm using OJB 1.0.3 with PB api. Frank -Ursprüngliche Nachricht- Von: Vasily Ivanov [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 12. September 2006 01:19 An: OJB Users List Betreff: Re: Support of database views Hi Frank, We used to work with views without any issue, just put view's name as table attribute in class-descriptor. However, you will only be able to read objects from that view. Regards, Vasily On 9/11/06, Hiller, Frank RD-AS2 [EMAIL PROTECTED] wrote: Short question: I couldn't find a functionality to deal with database views (create view...) within OJB. Is there a reason for that? Is the answer use ReportQuery. Thank you, Frank Confidentiality note: The information in this email and any attachment may contain confidential and proprietary information of Heidelberger Druckmaschinen AG and/or its affiliates and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you are hereby
RE: Support of database views
It was a good guess then ! Glad I could help, Charles. -Original Message- From: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] Sent: 19 September 2006 15:26 To: OJB Users List Subject: AW: Support of database views Yes, it works. Thank youFrank -Ursprüngliche Nachricht- Von: Charles Anthony [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 19. September 2006 16:09 An: OJB Users List Betreff: RE: Support of database views Well, that's my guess... -Original Message- From: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] Sent: 19 September 2006 15:08 To: OJB Users List Subject: AW: Support of database views Ok, I see. Setting object-cache class=org.apache.ojb.broker.cache.ObjectCacheEmptyImpl/ on the specific table (that actually is a view) resolves the problem? Frank -Ursprüngliche Nachricht- Von: Charles Anthony [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 19. September 2006 16:04 An: OJB Users List Betreff: RE: Support of database views Yes, but all (by default) all reads ARE transparently cached (to improve performance). So if you've read C, then you do an update of A or B, then you re-read C - you will not see the updates but the OLD version of C. It's a bit difficult to explain, and I'm obviously not being very clear. -Original Message- From: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] Sent: 19 September 2006 14:52 To: OJB Users List Subject: AW: Support of database views I do not expect to automatically update the object in cache representing the view. After the update of A or B I explicitely read the view. At that point my expactation was to retrieve the new value. The SQL statement returns the correct (new) value, but ojb uses the object from the cache with the old value. This confuses me a little. Best regards, Frank -Ursprüngliche Nachricht- Von: Charles Anthony [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 19. September 2006 15:23 An: OJB Users List Betreff: RE: Support of database views No, it's not really a bug; Let's say you have objects A, B and C where C is an objject mapped onto a view joining A B. OJB Caches objects on their Class + PK; when you update an object, it is ejected from the cache based on it's class and PK. So, let's say C with a PK of one is references A with a PK of 2 You read from C - C[1] is inserted in the cache You read A - A[2] is inserted in the cache You update A - A[2] is dropped from the cache but C[1] is still in the cache. OJB doesn't (and can't) know about the relationship between A C If all updates are done from OJB, and if you can derive the PK of C (in the above example) from A, then you could implement some kind of listener that says whenever A is updated, drop C from the cache You might also be able to specify that C should never be cached (by specifying the org.apache.ojb.broker.cache.ObjectCacheEmptyImpl in object-cache element for the class in the repostory.xml) Cheers, Charles. -Original Message- From: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] Sent: 19 September 2006 14:09 To: OJB Users List Subject: AW: Support of database views Additional information: When I explicitely remove the objects from the brokers internal cache (broker.removeFromCache(obj)) it works. Is it a bug? Frank -Ursprüngliche Nachricht- Von: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 19. September 2006 13:56 An: OJB Users List Betreff: AW: Support of database views Hi Vasily, using the view as a table (following your recommendation) shows a strange behaviour. When a field in a table is updated and the matching object returns the correct new value the object related to the view (spanning two tables ) still holds the old value for a long time (minutes). Have you (or soneome else) ever had such a problem? Is there something I can configure (in ojb.properties)? I'm using OJB 1.0.3 with PB api. Frank -Ursprüngliche Nachricht- Von: Vasily Ivanov [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 12. September 2006 01:19 An: OJB Users List Betreff: Re: Support of database views Hi Frank, We used to work with views without any issue, just put view's name as table attribute in class-descriptor. However, you will only be able to read objects from that view. Regards, Vasily On 9/11/06, Hiller, Frank RD-AS2 [EMAIL PROTECTED] wrote: Short question: I couldn't find a functionality to deal with database views (create view...) within OJB. Is there a reason for
TxCheck, JTA and Spring
We are using Spring and JTA in container to manage transactional DAOs. We have TxCheck enabled and when one of our transactional DAOs is called in JBoss, we get a No running tx found... message. Should we disable the TxCheck since we are not using PB transactions or does TxCheck handle this case and we just have something misconfigured? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
OJB-DBCP initial connection pool setting support
Hi, DBCP supports an initialSize property for initializing connections on startup, does OJB support this parameter? Thanks -Eric Disclaimer: This email may contain confidential and privileged material for the sole use of the intended recipient(s) and only for those purposes previously or herein authorized by the sender. Any review, use, distribution or disclosure by others, or use by the recipient for unauthorized purposes, is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.
Re: Support of database views
Yeah, I'm a bit late here. We do not use cache for objects retrieved from views, so the suggestion was correct. Also be aware that on big views (that join lots of table for instance) retrieving objects could be quite expensive. The thing is that db refreshes view each time you call it, unless you are using materialised views which is not the case in dynamic apps. We had some problems because of that. We had to get rid of views and connect to tables directly. Cheers, Vasily On 9/20/06, Hiller, Frank RD-AS2 [EMAIL PROTECTED] wrote: Yes, it works. Thank youFrank -Ursprüngliche Nachricht- Von: Charles Anthony [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 19. September 2006 16:09 An: OJB Users List Betreff: RE: Support of database views Well, that's my guess... -Original Message- From: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] Sent: 19 September 2006 15:08 To: OJB Users List Subject: AW: Support of database views Ok, I see. Setting object-cache class=org.apache.ojb.broker.cache.ObjectCacheEmptyImpl/ on the specific table (that actually is a view) resolves the problem? Frank -Ursprüngliche Nachricht- Von: Charles Anthony [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 19. September 2006 16:04 An: OJB Users List Betreff: RE: Support of database views Yes, but all (by default) all reads ARE transparently cached (to improve performance). So if you've read C, then you do an update of A or B, then you re-read C - you will not see the updates but the OLD version of C. It's a bit difficult to explain, and I'm obviously not being very clear. -Original Message- From: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] Sent: 19 September 2006 14:52 To: OJB Users List Subject: AW: Support of database views I do not expect to automatically update the object in cache representing the view. After the update of A or B I explicitely read the view. At that point my expactation was to retrieve the new value. The SQL statement returns the correct (new) value, but ojb uses the object from the cache with the old value. This confuses me a little. Best regards, Frank -Ursprüngliche Nachricht- Von: Charles Anthony [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 19. September 2006 15:23 An: OJB Users List Betreff: RE: Support of database views No, it's not really a bug; Let's say you have objects A, B and C where C is an objject mapped onto a view joining A B. OJB Caches objects on their Class + PK; when you update an object, it is ejected from the cache based on it's class and PK. So, let's say C with a PK of one is references A with a PK of 2 You read from C - C[1] is inserted in the cache You read A - A[2] is inserted in the cache You update A - A[2] is dropped from the cache but C[1] is still in the cache. OJB doesn't (and can't) know about the relationship between A C If all updates are done from OJB, and if you can derive the PK of C (in the above example) from A, then you could implement some kind of listener that says whenever A is updated, drop C from the cache You might also be able to specify that C should never be cached (by specifying the org.apache.ojb.broker.cache.ObjectCacheEmptyImpl in object-cache element for the class in the repostory.xml) Cheers, Charles. -Original Message- From: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] Sent: 19 September 2006 14:09 To: OJB Users List Subject: AW: Support of database views Additional information: When I explicitely remove the objects from the brokers internal cache (broker.removeFromCache(obj)) it works. Is it a bug? Frank -Ursprüngliche Nachricht- Von: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 19. September 2006 13:56 An: OJB Users List Betreff: AW: Support of database views Hi Vasily, using the view as a table (following your recommendation) shows a strange behaviour. When a field in a table is updated and the matching object returns the correct new value the object related to the view (spanning two tables ) still holds the old value for a long time (minutes). Have you (or soneome else) ever had such a problem? Is there something I can configure (in ojb.properties)? I'm using OJB 1.0.3 with PB api. Frank -Ursprüngliche Nachricht- Von: Vasily Ivanov [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 12. September 2006 01:19 An: OJB Users List Betreff: Re: Support of database views Hi Frank, We used to work with views without any issue, just put view's name as table attribute in class-descriptor. However, you will only be able to read objects from that view. Regards, Vasily On 9/11/06, Hiller, Frank RD-AS2 [EMAIL PROTECTED] wrote: Short question: I couldn't find a functionality to