OJB with JBossCache?
Are people using OJB with JBossCache? Or is the usual practice when deploying in JBoss to ignore that cache and add OSCache or JCS? Any preferences between the latter two? thanks, -steve Steve Clark ECOS Development Group [EMAIL PROTECTED] (970)226-9291 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ORA-00932 inconsistent datatypes with CLOB
I guess I had modified JdbcAccessImpl to add some print statements.
I have solved the problem. Here's what was happening:
I had code like this: crit.addGreaterThan(contains(clob_column,
'someval'), 0), because I needed to get SQL like this:
contains(clob_column, 'someval') 0. When OJB parsed the first parameter
to extract the referenced column, it decided (correctly) that it was
looking at a CLOB. So when it went to bind the second parameter (0), it
tried to handle it as a CLOB as well, which (of course) didn't work.
The workaround that I am using: I made a custom platform implementation
which overrides setObjectForStatement() to look for the special case where
a String containing a single digit is being treated as a CLOB and treat it
as an integer instead. This test, at least in my app, will pretty
reliably indicate this specific situation.
I'm not sure whether there's a cleaner solution short of making OJB aware
of functions and their specific return types.
As an aside, it sure would be nice to be able to add new Platform
implementations without having to put them into
org.apache.ojb.broker.platforms. A simple solution would be something
like this (in PlatformFactory):
private static String getClassnameFor(String platform)
{
String pf = Default;
if (platform != null)
{
+if (platform.indexOf('.') 0)
+{
+return platform;
+}
pf = platform;
}
return org.apache.ojb.broker.platforms.Platform +
pf.substring(0, 1).toUpperCase() + pf.substring(1) + Impl;
}
-steve
Steve Clark
ECOS Development Group
[EMAIL PROTECTED]
(970)226-9291
Armin Waibel [EMAIL PROTECTED]
07/28/2006 11:35 AM
Please respond to
OJB Users List ojb-user@db.apache.org
To
OJB Users List ojb-user@db.apache.org
cc
Subject
Re: ORA-00932 inconsistent datatypes with CLOB
Hi Steve,
do you use a modified version of JdbcAccessImpl? The stack trace show
line 327 in method 'executeQuery' as causer but this doesn't match with
1.0.4 version of this class (SNV: 365259)
...
at
org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeQuery(JdbcAccessImpl.java:327)
regards,
Armin
[EMAIL PROTECTED] wrote:
I am using OJB 1.0.4, Persistence Broker, Oracle 10g, Oracle Text.
I have a query which is using the Oracle Text contains() function to
search in a CLOB. It is throwing ORA-00932: inconsistent datatypes:
expected - got CLOB.
If I replace the ?'s with appropriate values and do
Statement.executeQuery(), i.e. do the binding by hand and pass this
query
straight to JDBC, then it works. Similarly, if I give it to sqlplus, it
works. Can anybody tell me why it fails when produced by OJB? The one
possibly weird thing that I can come up with is that 'SPECIES', the
value
that's being sought in the CLOB column, is not a bind variable in the
PreparedStatement but rather a literal (I couldn't figure out how to do
it
otherwise with PB).
Any insights?
thanks,
-steve
Steve Clark
ECOS Development Group
[EMAIL PROTECTED]
(970)226-9291
Full stack trace:
An error has occurred
org.apache.ojb.broker.PersistenceBrokerSQLException: * SQLException
during
execution of sql-statement: * sql statement was 'SELECT DISTINCT
A0.ACTIVITY_ID,A0.PRIMARY_WORK_TYPE_ID,A0.IS_EARLY_PLANNING,A0.IS_MITIGATION_REQUIRED,A0.ACRES_IMPACTED,A0.MILES_IMPACTED,A0.S18_FISHWAY_PRESCRIPTIONS,A0.S18_FISHWAY_MILES,A0.OTHER_RIVER_MILES,A0.FWS_RESPONSE_DATE,A0.FINAL_DECISION_DATE,A0.PERMIT_DATE,A0.PERMIT_AGENCY_ID,A0.OTHER_PERMIT_AGENCY,A0.REF_ENVIR_REVIEW,A0.REF_FOIA_CODE,A0.FEDACT_REVIEW_TYPE_ID,A0.APPLICANT_TYPE_ID,A0.PERMIT_STATUS_ID,A0.FWS_RECOMMENDATION,A1.SEQUENCE
as ojb_col_21 FROM TAILS_DEV.FEDERAL_ACTIVITY A0 INNER JOIN
TAILS_DEV.ACTIVITY A1 ON A0.ACTIVITY_ID=A1.ACTIVITY_ID WHERE
A0.ACTIVITY_ID IN (SELECT DISTINCT B0.ACTIVITY_ID FROM
TAILS_DEV.FEDERAL_ACTIVITY B0 LEFT OUTER JOIN TAILS_DEV.ACTIVITY B1 ON
B0.ACTIVITY_ID=B1.ACTIVITY_ID LEFT OUTER JOIN TAILS_DEV.ACTIVITY_EVENT
B2
ON B1.ACTIVITY_ID=B2.ACTIVITY_ID LEFT OUTER JOIN TAILS_DEV.EVENT B3 ON
B2.EVENT_ID=B3.EVENT_ID LEFT OUTER JOIN TAILS_DEV.ACTIVITY B4 ON
B0.ACTIVITY_ID=B4.ACTIVITY_ID LEFT OUTER JOIN
TAILS_DEV.ACTIVITY_OTHER_OFFICE B5 ON B4.ACTIVITY_ID=B5.ACTIVITY_ID LEFT
OUTER JOIN ECOS_DATA.ECOS_OFFICE B6 ON B5.OFFICE_ID=B6.OFFICE_ID WHERE (
contains(B3.DESCRIPTION,'SPECIES') ?) AND (B4.LEAD_OFFICE_ID = ? OR
(B6.OFFICE_ID = ?))) ORDER BY 21' * Exception message is [ORA-00932:
inconsistent datatypes: expected - got CLOB ] * Vendor error code [932]
*
SQL state code [42000]
org.apache.ojb.broker.PersistenceBrokerException:
org.apache.ojb.broker.PersistenceBrokerSQLException:
* SQLException during execution of sql-statement:
* sql statement was 'SELECT DISTINCT
ORA-00932 inconsistent datatypes with CLOB
I am using OJB 1.0.4, Persistence Broker, Oracle 10g, Oracle Text. I have a query which is using the Oracle Text contains() function to search in a CLOB. It is throwing ORA-00932: inconsistent datatypes: expected - got CLOB. If I replace the ?'s with appropriate values and do Statement.executeQuery(), i.e. do the binding by hand and pass this query straight to JDBC, then it works. Similarly, if I give it to sqlplus, it works. Can anybody tell me why it fails when produced by OJB? The one possibly weird thing that I can come up with is that 'SPECIES', the value that's being sought in the CLOB column, is not a bind variable in the PreparedStatement but rather a literal (I couldn't figure out how to do it otherwise with PB). Any insights? thanks, -steve Steve Clark ECOS Development Group [EMAIL PROTECTED] (970)226-9291 Full stack trace: An error has occurred org.apache.ojb.broker.PersistenceBrokerSQLException: * SQLException during execution of sql-statement: * sql statement was 'SELECT DISTINCT A0.ACTIVITY_ID,A0.PRIMARY_WORK_TYPE_ID,A0.IS_EARLY_PLANNING,A0.IS_MITIGATION_REQUIRED,A0.ACRES_IMPACTED,A0.MILES_IMPACTED,A0.S18_FISHWAY_PRESCRIPTIONS,A0.S18_FISHWAY_MILES,A0.OTHER_RIVER_MILES,A0.FWS_RESPONSE_DATE,A0.FINAL_DECISION_DATE,A0.PERMIT_DATE,A0.PERMIT_AGENCY_ID,A0.OTHER_PERMIT_AGENCY,A0.REF_ENVIR_REVIEW,A0.REF_FOIA_CODE,A0.FEDACT_REVIEW_TYPE_ID,A0.APPLICANT_TYPE_ID,A0.PERMIT_STATUS_ID,A0.FWS_RECOMMENDATION,A1.SEQUENCE as ojb_col_21 FROM TAILS_DEV.FEDERAL_ACTIVITY A0 INNER JOIN TAILS_DEV.ACTIVITY A1 ON A0.ACTIVITY_ID=A1.ACTIVITY_ID WHERE A0.ACTIVITY_ID IN (SELECT DISTINCT B0.ACTIVITY_ID FROM TAILS_DEV.FEDERAL_ACTIVITY B0 LEFT OUTER JOIN TAILS_DEV.ACTIVITY B1 ON B0.ACTIVITY_ID=B1.ACTIVITY_ID LEFT OUTER JOIN TAILS_DEV.ACTIVITY_EVENT B2 ON B1.ACTIVITY_ID=B2.ACTIVITY_ID LEFT OUTER JOIN TAILS_DEV.EVENT B3 ON B2.EVENT_ID=B3.EVENT_ID LEFT OUTER JOIN TAILS_DEV.ACTIVITY B4 ON B0.ACTIVITY_ID=B4.ACTIVITY_ID LEFT OUTER JOIN TAILS_DEV.ACTIVITY_OTHER_OFFICE B5 ON B4.ACTIVITY_ID=B5.ACTIVITY_ID LEFT OUTER JOIN ECOS_DATA.ECOS_OFFICE B6 ON B5.OFFICE_ID=B6.OFFICE_ID WHERE ( contains(B3.DESCRIPTION,'SPECIES') ?) AND (B4.LEAD_OFFICE_ID = ? OR (B6.OFFICE_ID = ?))) ORDER BY 21' * Exception message is [ORA-00932: inconsistent datatypes: expected - got CLOB ] * Vendor error code [932] * SQL state code [42000] org.apache.ojb.broker.PersistenceBrokerException: org.apache.ojb.broker.PersistenceBrokerSQLException: * SQLException during execution of sql-statement: * sql statement was 'SELECT DISTINCT A0.ACTIVITY_ID,A0.PRIMARY_WORK_TYPE_ID,A0.IS_EARLY_PLANNING,A0.IS_MITIGATION_REQUIRED,A0.ACRES_IMPACTED,A0.MILES_IMPACTED,A0.S18_FISHWAY_PRESCRIPTIONS,A0.S18_FISHWAY_MILES,A0.OTHER_RIVER_MILES,A0.FWS_RESPONSE_DATE,A0.FINAL_DECISION_DATE,A0.PERMIT_DATE,A0.PERMIT_AGENCY_ID,A0.OTHER_PERMIT_AGENCY,A0.REF_ENVIR_REVIEW,A0.REF_FOIA_CODE,A0.FEDACT_REVIEW_TYPE_ID,A0.APPLICANT_TYPE_ID,A0.PERMIT_STATUS_ID,A0.FWS_RECOMMENDATION,A1.SEQUENCE as ojb_col_21 FROM TAILS_DEV.FEDERAL_ACTIVITY A0 INNER JOIN TAILS_DEV.ACTIVITY A1 ON A0.ACTIVITY_ID=A1.ACTIVITY_ID WHERE A0.ACTIVITY_ID IN (SELECT DISTINCT B0.ACTIVITY_ID FROM TAILS_DEV.FEDERAL_ACTIVITY B0 LEFT OUTER JOIN TAILS_DEV.ACTIVITY B1 ON B0.ACTIVITY_ID=B1.ACTIVITY_ID LEFT OUTER JOIN TAILS_DEV.ACTIVITY_EVENT B2 ON B1.ACTIVITY_ID=B2.ACTIVITY_ID LEFT OUTER JOIN TAILS_DEV.EVENT B3 ON B2.EVENT_ID=B3.EVENT_ID LEFT OUTER JOIN TAILS_DEV.ACTIVITY B4 ON B0.ACTIVITY_ID=B4.ACTIVITY_ID LEFT OUTER JOIN TAILS_DEV.ACTIVITY_OTHER_OFFICE B5 ON B4.ACTIVITY_ID=B5.ACTIVITY_ID LEFT OUTER JOIN ECOS_DATA.ECOS_OFFICE B6 ON B5.OFFICE_ID=B6.OFFICE_ID WHERE ( my_contains(B3.DESCRIPTION,'E') ?) AND (B4.LEAD_OFFICE_ID = ? OR (B6.OFFICE_ID = ?))) ORDER BY 21' * Exception message is [ORA-00932: inconsistent datatypes: expected - got CLOB ] * Vendor error code [932] * SQL state code [42000] at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryReferenceBroker.java:272) at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryReferenceBroker.java:284) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(PersistenceBrokerImpl.java:1475) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery(DelegatingPersistenceBroker.java:383) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery(DelegatingPersistenceBroker.java:383) at gov.doi.tat.odmg.Select.byCriteria(Select.java:314) at gov.doi.tat.odmg.Select.byCriteria(Select.java:265) at gov.doi.tat.odmg.Select.byCriteriaWithSubQuery(Select.java:242) at gov.doi.tails.dao.odmg.AbstractSearchDaoImpl.search(AbstractSearchDaoImpl.java:306) at gov.doi.tails.biz.AbstractSearchMgr.search(AbstractSearchMgr.java:129) at gov.doi.tails.actions.AbstractSearchAction.doSearch(AbstractSearchAction.java:224) at
Criteria.addSql() vs. attributes (not columns)
I am using PB in 1.0.4. I'm trying to call the Oracle Text contains() function in my query, so I want to end up with something like this: select ... from table1 A0, table2 A1 where ... and contains(A1.description, 'something', 1); The only way I can see to get there is by using addSql(), but I don't know how to get the attribute - column mapping and the A1 alias applied - there is a 'description' column in both tables, so it doesn't work to just use addSql(contains(description, 'something', 1)). Is there a way to accomplish this? -steve Steve Clark ECOS Development Group [EMAIL PROTECTED] (970)226-9291 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why do queries for Identity retrieve all columns?
Ok, I guess I was living in the past - OJB used to do these as two separate queries (get PKs, then retrieve matched objects). Didn't realize that it was now working as you describe (good news). I have rewritten my code to use a subquery and thus get the best of both worlds - I can apply distinct to just the pk in the subquery, and still get all of the matching rows with a single SQL call. Thanks for the clarification, Armin. -steve Steve Clark ECOS Development Group [EMAIL PROTECTED] (970)226-9291 Armin Waibel [EMAIL PROTECTED] 06/26/2006 05:22 PM Please respond to OJB Users List ojb-user@db.apache.org To OJB Users List ojb-user@db.apache.org cc Subject Re: Why do queries for Identity retrieve all columns? [EMAIL PROTECTED] wrote: Armin, I'm using 1.0.4. I am not doing a QueryByIdentity. I am doing a QueryByCriteria. So when I do: QueryByCriteria query = QueryFactory.newQuery(Article.class, criteria, true); broker.getCollectionByQuery(query); my expectation would be that the SQL generated would be: -- Which Identities match my criteria? select distinct Artikel_Nr from Artikel where ... -- for cache misses: select Artikel_Nr, Artikelname, Lieferanten_Nr, ... from Artikel where Artikel_Nr = ? This isn't the query/cache-strategy of OJB, because in this case the cache should match most objects from the database (this would require a really big cache), else we will get many single select statements for the missed objects in cache. But instead, here's what happens: -- Which Identities match my criteria? select distinct Artikel_Nr, Artikelname, Lieferanten_Nr, ... from Artikel where ... -- for cache misses: select Artikel_Nr, Artikelname, Lieferanten_Nr, ... from Artikel where Artikel_Nr = ? This isn't the strategy of OJB. First OJB execute the distinct query, then OJB loop through the result set read the Identity of the row and check for cache match. If true the object will be read from cache, else the whole object will be materialized from result set row. When all of the irrelevant columns are included in the first query, that query slows down dramatically. So what I'm wondering is why the first query includes all of these columns that it doesn't need, rather than just retrieving the PKs? See above. ... millions of rows in my result set; afterwards, I have about 700. If I query just for the PK, the query takes a few seconds to return the 700 PK ... You could do that in two steps: First use a ReportQuery to retrieve all PK's (e.g. with PB.getReportQueryIteratorByQuery(q) or getCollectionByQuery), then use PB.getObjectByIdentity(...) to materialize the object. In this case the worst case scenario would execute 701 select statements to materialize the objects (if you use the two-level cache and none-lazy references, OJB will need additional queries to lookup the referenced objects). http://db.apache.org/ojb/docu/guides/query.html#Report+Queries http://db.apache.org/ojb/docu/tutorials/pb-tutorial.html#Find+object+by+primary+key regards, Armin - 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]
Why do queries for Identity retrieve all columns?
I have always wondered about this, but now I am encountering a serious performance problem which results from this policy. When executing a Query, OJB generates two different rounds of SQL. The first round is used just to determine the Identity of any matching objects. These Identities are then checked against the cache, and the database is queried again to materialize any missing objects. Both the first round and the second retrieve all of the known columns, even though the first one only needs the PKs. My situation: I have a table with about 20 columns, including some large text columns. I'm doing a query which ends up joining to a dozen other tables, and I have to use 'distinct'. Before applying 'distinct', I have millions of rows in my result set; afterwards, I have about 700. If I query just for the PK, the query takes a few seconds to return the 700 PK values. If I query for all of the columns, it takes 3 minutes to distinct-ify the millions of duplicate rows down to the 700 actually distinct ones. Does anybody have a solution? Why does the initial query have to retrieve all of the columns instead of just the PK(s)? thanks, -steve Steve Clark ECOS Development Group [EMAIL PROTECTED] (970)226-9291 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why do queries for Identity retrieve all columns?
Armin, I'm using 1.0.4. I am not doing a QueryByIdentity. I am doing a QueryByCriteria. So when I do: QueryByCriteria query = QueryFactory.newQuery(Article.class, criteria, true); broker.getCollectionByQuery(query); my expectation would be that the SQL generated would be: -- Which Identities match my criteria? select distinct Artikel_Nr from Artikel where ... -- for cache misses: select Artikel_Nr, Artikelname, Lieferanten_Nr, ... from Artikel where Artikel_Nr = ? But instead, here's what happens: -- Which Identities match my criteria? select distinct Artikel_Nr, Artikelname, Lieferanten_Nr, ... from Artikel where ... -- for cache misses: select Artikel_Nr, Artikelname, Lieferanten_Nr, ... from Artikel where Artikel_Nr = ? When all of the irrelevant columns are included in the first query, that query slows down dramatically. So what I'm wondering is why the first query includes all of these columns that it doesn't need, rather than just retrieving the PKs? thanks, -steve Steve Clark ECOS Development Group [EMAIL PROTECTED] (970)226-9291 Armin Waibel [EMAIL PROTECTED] 06/26/2006 11:55 AM Please respond to OJB Users List ojb-user@db.apache.org To OJB Users List ojb-user@db.apache.org cc Subject Re: Why do queries for Identity retrieve all columns? Hi Steve, which version of OJB do you use? Do you use Identity xyz = broker.serviceIdentity().buildIdentity(Article.class, new Integer(7)); Collection col = broker.getObjectByIdentity(xyz) or a QueryByIdentity object? regards, Armin [EMAIL PROTECTED] wrote: I have always wondered about this, but now I am encountering a serious performance problem which results from this policy. When executing a Query, OJB generates two different rounds of SQL. The first round is used just to determine the Identity of any matching objects. These Identities are then checked against the cache, and the database is queried again to materialize any missing objects. Both the first round and the second retrieve all of the known columns, even though the first one only needs the PKs. My situation: I have a table with about 20 columns, including some large text columns. I'm doing a query which ends up joining to a dozen other tables, and I have to use 'distinct'. Before applying 'distinct', I have millions of rows in my result set; afterwards, I have about 700. If I query just for the PK, the query takes a few seconds to return the 700 PK values. If I query for all of the columns, it takes 3 minutes to distinct-ify the millions of duplicate rows down to the 700 actually distinct ones. Does anybody have a solution? Why does the initial query have to retrieve all of the columns instead of just the PK(s)? thanks, -steve Steve Clark ECOS Development Group [EMAIL PROTECTED] (970)226-9291 - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Old bug returns: UPDATE when accept-locks=false
What I am trying to accomplish is to set the CongDist class as read-only. I want to be able to make LocationImpl 's point at CongDists, but I never want to update the CONG_DIST table. I have ImplicitLocking=false and accept-locks=false, so I'm surprised to see and UPDATE being generated for CONG_DIST. Is there really no way to prevent this update? My code was like this: CongDist cd = new CongDist(); cd.setKey(key); cd.setOtherFields(appropriate values); tx.begin(); tx.lock(location, Transaction.WRITE); tx.lock(location.getCongDist(), Transaction.READ); tx.lock(cd, Transaction.READ); location.setCongDist(cd); tx.commit(); The values set in cd matched values already in the database, but an UPDATE was nevertheless generated. I have worked around this by retrieving cd via an OJB query before using it, but I still wonder if there really is no way to mark a table as completely off-limits for update? -steve Steve Clark ECOS Development Group [EMAIL PROTECTED] (970)226-9291 Armin Waibel [EMAIL PROTECTED] 11/19/2005 08:13 PM Please respond to OJB Users List ojb-user@db.apache.org To OJB Users List ojb-user@db.apache.org cc Subject Re: Old bug returns: UPDATE when accept-locks=false Hi Steve, [EMAIL PROTECTED] wrote: I am seeing what looks like an old OJB bug resurfacing, and wonder if anybody can shed some light. I have an object with a reference to a read-only lookup table, and also a collection of entries from another read-only lookup table. Both lookups have accept-locks=false: class-descriptor class=LocationImpl ... reference-descriptor name=congDist class=CongDist auto-update=none auto-delete=none foreignkey ... / /reference-descriptor collection-descriptor name=ecoRegions class=EcoRegionImpl auto-delete=link auto-update=none fk-pointing... / /collection-descriptor /class-descriptor class-descriptor class=CongDist schema=SUPPORT table=CONG_DIST accept-locks=false ... / class-descriptor class=EcoRegionImpl schema=SUPPORT table=ECOREGION accept-locks=false ... / I update an existing LocationImpl like this: tx.lock(location, tx.WRITE); tx.lock(location.getCongDist(), tx.READ); tx.lock(newCongDist, tx.READ); location.setCongDist(newCongDist); OJB sometimes generates an UPDATE against SUPPORT.CONG_DIST, which fails because I don't have update permission in that schema. The UPDATE is not actually attempting to change any values, it's just repeating the existing ones. I setup a test case similar to yours tx.begin(); tx.lock(book, Transaction.WRITE); tx.lock(book.getPublisher(), Transaction.READ); tx.lock(p_2, Transaction.READ); book.setPublisher(p_2); tx.commit(); Book has a 1:1 reference with Publisher. The Publisher objects are never updated, only the Book object. I assume that this can't be correct behavior by OJB - it should never be generating an UPDATE against a class with accept-locks=false. The locking settings are independent from the object state detection in ODMG. E.g. if you set isolation-level to 'none' on class-descriptor the associated objects will never be locked but still inserted, updated, deleted if OJB detects any changes. The 'accept-locks' attribute definition seems strange to me. Does it make sense to skip the locking of an object when the locking call was an implicit one? The current implemented behavior is different. With accept-locks=false OJB will always skip locking (same behavior as isolation-level=none). What do you expect when using this attribute? regards, Armin The same thing sometimes happens with the ECOREGION table. In some cases, the congDist or ecoRegion object in question doesn't actually come from OJB - it is created independently, but its PK value matches a value already in the table: newCongDist = new CongDist(); newCongDist.setKey(valid pk from SUPPORT.CONG_DIST); newCongDist.setOtherData(matching other data from SUPPORT.CONG_DIST); We are using ODMG from CVS HEAD (from 1.0.4 branch) as of 4 November. Can anybody help? thanks, -steve Steve Clark ECOS Development Group [EMAIL PROTECTED] (970)226-9291 - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Old bug returns: UPDATE when accept-locks=false
I am seeing what looks like an old OJB bug resurfacing, and wonder if anybody can shed some light. I have an object with a reference to a read-only lookup table, and also a collection of entries from another read-only lookup table. Both lookups have accept-locks=false: class-descriptor class=LocationImpl ... reference-descriptor name=congDist class=CongDist auto-update=none auto-delete=none foreignkey ... / /reference-descriptor collection-descriptor name=ecoRegions class=EcoRegionImpl auto-delete=link auto-update=none fk-pointing... / /collection-descriptor /class-descriptor class-descriptor class=CongDist schema=SUPPORT table=CONG_DIST accept-locks=false ... / class-descriptor class=EcoRegionImpl schema=SUPPORT table=ECOREGION accept-locks=false ... / I update an existing LocationImpl like this: tx.lock(location, tx.WRITE); tx.lock(location.getCongDist(), tx.READ); tx.lock(newCongDist, tx.READ); location.setCongDist(newCongDist); OJB sometimes generates an UPDATE against SUPPORT.CONG_DIST, which fails because I don't have update permission in that schema. The UPDATE is not actually attempting to change any values, it's just repeating the existing ones. I assume that this can't be correct behavior by OJB - it should never be generating an UPDATE against a class with accept-locks=false. The same thing sometimes happens with the ECOREGION table. In some cases, the congDist or ecoRegion object in question doesn't actually come from OJB - it is created independently, but its PK value matches a value already in the table: newCongDist = new CongDist(); newCongDist.setKey(valid pk from SUPPORT.CONG_DIST); newCongDist.setOtherData(matching other data from SUPPORT.CONG_DIST); We are using ODMG from CVS HEAD (from 1.0.4 branch) as of 4 November. Can anybody help? thanks, -steve Steve Clark ECOS Development Group [EMAIL PROTECTED] (970)226-9291 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
PATCH: AbstractIndirectionHandler#getBroker() returns null
When I upgraded to recent CVS 1.0.4 HEAD, I started getting constant NPEs in equals() calls to proxies. The problem is a bug in AbstractIndirectionHandler; here's a patch. RCS file: /home/cvspublic/db-ojb/src/java/org/apache/ojb/broker/core/proxy/AbstractIndirectionHandler.java,v retrieving revision 1.1.2.2 diff -c -r1.1.2.2 AbstractIndirectionHandler.java *** AbstractIndirectionHandler.java 17 Aug 2005 21:19:39 - 1.1.2.2 --- AbstractIndirectionHandler.java 26 Sep 2005 19:45:43 - *** *** 216,223 _broker = (PersistenceBrokerInternal) PersistenceBrokerFactory.createPersistenceBroker(getBrokerKey()); // TODO: Better way? _needsClose = true; - broker = _broker; } } return broker; } --- 216,223 _broker = (PersistenceBrokerInternal) PersistenceBrokerFactory.createPersistenceBroker(getBrokerKey()); // TODO: Better way? _needsClose = true; } + broker = _broker; } return broker; } -steve Steve Clark ECOS Development Group [EMAIL PROTECTED] (970)226-9291 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ObjectEnvelopeTable: Unexpected behavior
I am using 1.0.4 from CVS as of yesterday. I am getting this exception, thrown at ObjectEnvelopeTable line 602 (the comment is the infamous should never occur). The behavior was introduced in 1.32.2.22 - I have verified that it does not occur in 1.32.2.21. What is happening is this: I am creating a new object A, which has a reference to B, which in turn has a reference to C. I have a write lock on A, a read lock on B, and no lock at all on C. ImplicitLocking is false. The insert logic is cascading anyway - the exception is thrown when cascadeInsertSingleReferences() encounters C, which is not new and is not known to the Transaction. Here's the top of the stack trace: java.lang.RuntimeException: Unexpected behavior at org.apache.ojb.odmg.ObjectEnvelopeTable.cascadeInsertSingleReferences(ObjectEnvelopeTable.java:603) at org.apache.ojb.odmg.ObjectEnvelopeTable.cascadeInsertFor(ObjectEnvelopeTable.java:556) at org.apache.ojb.odmg.ObjectEnvelopeTable.cascadeInsertSingleReferences(ObjectEnvelopeTable.java:605) at org.apache.ojb.odmg.ObjectEnvelopeTable.cascadeInsertFor(ObjectEnvelopeTable.java:556) at org.apache.ojb.odmg.ObjectEnvelopeTable.cascadeInsertSingleReferences(ObjectEnvelopeTable.java:605) at org.apache.ojb.odmg.ObjectEnvelopeTable.cascadeInsertFor(ObjectEnvelopeTable.java:556) at org.apache.ojb.odmg.ObjectEnvelopeTable.cascadeMarkedForInsert(ObjectEnvelopeTable.java:536) at org.apache.ojb.odmg.ObjectEnvelopeTable.cascadingDependents(ObjectEnvelopeTable.java:505) at org.apache.ojb.odmg.ObjectEnvelopeTable.writeObjects(ObjectEnvelopeTable.java:170) at org.apache.ojb.odmg.TransactionImpl.doWriteObjects(TransactionImpl.java:384) at org.apache.ojb.odmg.TransactionImpl.prepareCommit(TransactionImpl.java:743) at org.apache.ojb.odmg.TransactionImpl.commit(TransactionImpl.java:679) Why should cascadingDependents() even be called here? I'm unclear whether 1.32.2.22 introduced the behavior and is therefore wrong, or whether it simply exposed some other problem. thanks, -steve Steve Clark ECOS Development Group [EMAIL PROTECTED] (970)226-9291 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ObjectEnvelopeTable: Unexpected behavior
Armin,
Thanks for the quick response. This patch does fix the error for me.
I'm still confused about why this code is getting called at all - it looks
like there is some implicit locking happening, even though
ImplicitLocking=false. Am I misunderstanding what's going on?
thanks,
-steve
Steve Clark
ECOS Development Group
[EMAIL PROTECTED]
(970)226-9291
Armin Waibel [EMAIL PROTECTED]
09/23/2005 12:51 PM
Please respond to
OJB Users List ojb-user@db.apache.org
To
OJB Users List ojb-user@db.apache.org
cc
Subject
Re: ObjectEnvelopeTable: Unexpected behavior
Hi Steve,
seems I had fixed a bug and introduce another bug - sorry.
The insert logic is cascading anyway - the exception is thrown when
cascadeInsertSingleReferences() encounters C, which is not new and is
not
known to the Transaction. Here's the top of the stack trace:
If C is not new and unknown nothing should happen. Think the code
section throwing the exception should be removed.
So could you try to replace ObjectEnvelopeTable line 589 to 605 with:
if(!alreadyPrepared.contains(oid))
{
ObjectEnvelope depMod = getByIdentity(oid);
// if the object isn't registered and is a new object, register it
// else we have nothing to do
if(depMod == null rt.isNew())
{
getTransaction().lockAndRegister(rt, Transaction.WRITE, false,
getTransaction().getRegistrationList());
depMod = getByIdentity(oid);
cascadeInsertFor(depMod, alreadyPrepared);
}
}
Then only unregistered new objects will be performed in cascade insert.
Does this solve your problem?
regards,
Armin
[EMAIL PROTECTED] wrote:
I am using 1.0.4 from CVS as of yesterday. I am getting this exception,
thrown at ObjectEnvelopeTable line 602 (the comment is the infamous
should never occur). The behavior was introduced in 1.32.2.22 - I
have
verified that it does not occur in 1.32.2.21.
What is happening is this: I am creating a new object A, which has a
reference to B, which in turn has a reference to C. I have a write lock
on A, a read lock on B, and no lock at all on C. ImplicitLocking is
false.
The insert logic is cascading anyway - the exception is thrown when
cascadeInsertSingleReferences() encounters C, which is not new and is
not
known to the Transaction. Here's the top of the stack trace:
java.lang.RuntimeException: Unexpected behavior
at
org.apache.ojb.odmg.ObjectEnvelopeTable.cascadeInsertSingleReferences(ObjectEnvelopeTable.java:603)
at
org.apache.ojb.odmg.ObjectEnvelopeTable.cascadeInsertFor(ObjectEnvelopeTable.java:556)
at
org.apache.ojb.odmg.ObjectEnvelopeTable.cascadeInsertSingleReferences(ObjectEnvelopeTable.java:605)
at
org.apache.ojb.odmg.ObjectEnvelopeTable.cascadeInsertFor(ObjectEnvelopeTable.java:556)
at
org.apache.ojb.odmg.ObjectEnvelopeTable.cascadeInsertSingleReferences(ObjectEnvelopeTable.java:605)
at
org.apache.ojb.odmg.ObjectEnvelopeTable.cascadeInsertFor(ObjectEnvelopeTable.java:556)
at
org.apache.ojb.odmg.ObjectEnvelopeTable.cascadeMarkedForInsert(ObjectEnvelopeTable.java:536)
at
org.apache.ojb.odmg.ObjectEnvelopeTable.cascadingDependents(ObjectEnvelopeTable.java:505)
at
org.apache.ojb.odmg.ObjectEnvelopeTable.writeObjects(ObjectEnvelopeTable.java:170)
at
org.apache.ojb.odmg.TransactionImpl.doWriteObjects(TransactionImpl.java:384)
at
org.apache.ojb.odmg.TransactionImpl.prepareCommit(TransactionImpl.java:743)
at
org.apache.ojb.odmg.TransactionImpl.commit(TransactionImpl.java:679)
Why should cascadingDependents() even be called here? I'm unclear
whether
1.32.2.22 introduced the behavior and is therefore wrong, or whether it
simply exposed some other problem.
thanks,
-steve
Steve Clark
ECOS Development Group
[EMAIL PROTECTED]
(970)226-9291
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Joining a subquery to parent across non-decomposed m:n
I have a query that I can't figure out how to write. I'm using 1.0.4 and
PersistenceBroker. Here's my situation:
Project has a Collection of Activities; this is a non-decomposed m:n via
ACTIVITY_PROJECT.
Activity has attribute 'conclusionDate'.
I want to find all Projects for which every Activity has a non-null
conclusionDate. In SQL, here's the query I'm aiming for:
SELECT DISTINCT A0.PROJECT_ID, count(A2.ACTIVITY_ID)
FROM PROJECT A0
INNER JOIN ACTIVITY_PROJECT A1 ON A0.PROJECT_ID=A1.PROJECT_ID
INNER JOIN ACTIVITY A2 ON A1.ACTIVITY_ID=A2.ACTIVITY_ID
WHERE NOT EXISTS
(SELECT B0.ACTIVITY_ID FROM ACTIVITY B0, ACTIVITY_PROJECT B1
WHERE B0.ACTIVITY_ID=B1.ACTIVITY_ID
AND B1.PROJECT_ID=A1.PROJECT_ID
AND B0.CONCLUSION_DATE IS NULL);
Here's pseudocode for what I'm trying to do:
subCrit = conclusionDate is not null
// This is the problematic line - how to join to the parent query?
subCrit.addEqualToField(activityId, Criteria.PARENT_QUERY_PREFIX
+ activityId)
ReportQueryByCriteria subQuery =
QueryFactory.newReportQuery(Activity.class, subCrit);
subQuery.setAttributes({ activityId });
crit = new Criteria();
crit.addNotExists(subQuery);
What I can't figure out is how to get the join right in the subquery.
Any suggestions?
thanks,
-steve
Steve Clark
ECOS Development Group
[EMAIL PROTECTED]
(970)226-9291
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Steve Clark is out of the office.
I will be out of the office starting 07/15/2005 and will not return until 08/15/2005. If you need help with ROAR or TAILS while I am gone, please contact Mariana Muller (by FWS Notes email or at 970-226-9447). Otherwise, I will respond to your email as soon as possible when I return. thanks, -steve Steve Clark ECOS Development Group [EMAIL PROTECTED] (970)226-9291 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Steve Clark is out of the office.
I will be out of the office starting 07/15/2005 and will not return until 08/15/2005. I am out of the office until Monday, August 15, and I will not see your email until I return. If you need help with ROAR or TAILS while I am gone, please contact Mariana Muller (by FWS Notes email or at 970-226-9447). Otherwise, I will respond to your email as soon as possible when I return. thanks, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
setPathOuterJoin() in 1.0.4
Is setPathOuterJoin() supposed to get a path or a single path component? i.e., if I have an attribute path activity.staff.firstName and I want to force an outer join to the staff table, should I call setPathOuterJoin(staff) or setPathOuterJoin(activity.staff)? The name of the method suggests the latter (which I'd think would also be more useful), but the code expects the former: In SqlQueryStatement.java:1069 (in 1.75.2.8, which is the latest on the 1.0 branch), it's checking against ObjectReferenceDescriptor.getAttributeName(), which is just staff. It would seem much more useful to use the full path (in SqlQueryStatement, this would mean testing attrPath rather than attr) - what if I have two different paths to reach the staff object and I want inner joins along one path and outer along the other? Probably either the method name should be changed to setAttributeOuterJoin() or the implementation should be changed to accept a path. -steve Steve Clark ECOS Development Group [EMAIL PROTECTED] (970)226-9291 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: a problem about oracle connection leak
You need to call broker.close() when you are done with each broker. You
are actually asking for 500 simultaneously active brokers.
-steve
Steve Clark
ECOS Development Group
[EMAIL PROTECTED]
(970)226-9291
Wang Lei [EMAIL PROTECTED]
05/24/2005 09:48 AM
Please respond to
OJB Users List ojb-user@db.apache.org
To
ojb-user@db.apache.org
cc
Subject
a problem about oracle connection leak
I have a stange a problem.
At first i design a table by the following script
CREATE TABLE MY_TEST
(
TEST_ID INTEGER
)
I also write a class whick is mapping to the table
package junit.entity;
public class MyTest
{
private int testId;
/**
* @return
*/
public int getTestId()
{
return testId;
}
/**
* @param testId */
public void setTestId(int testId)
{
this.testId = testId;
}
}
I write a descriptor in the xml file repository.xml
class-descriptor class=junit.entity.MyTest table=MY_TEST
field-descriptor autoincrement=true column=TEST_ID
jdbc-type=INTEGER name=testId primarykey=true/
/class-descriptor
I configure the pool as this
connection-pool maxActive=20 maxIdle=10 whenExhaustedAction=2
maxWait=2000 /
this configuration is the same as ojb.properties.
I use the following configuration
ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl
ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCachePerBrokerImpl.
I write a multi-thread class to test ojb and have a strange problem
At first i run the class on my computer on oracle9i in the
company.Everything is fine.
Later i run the class on the computer on oracle9i in the client.I found a
connection leak that the connections increase fast.
after a while, it established more than 200 connections.
I got a exception.
org.apache.ojb.broker.PBFactoryException: Borrow broker from pool failed,
using PBKey org.apache.ojb.broker.PBKey: jcdAlias=oracle,
user=ideal_bright, password=*
at
org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl.createPersistenceBroker(Unknown
Source)
at
org.apache.ojb.broker.core.PersistenceBrokerFactoryBaseImpl.defaultPersistenceBroker(Unknown
Source)
at
org.apache.ojb.broker.PersistenceBrokerFactory.defaultPersistenceBroker(Unknown
Source)
at junit.entity.MyTest.main(MyTest.java:86)
Caused by: java.util.NoSuchElementException: Timeout waiting for idle
object
at
org.apache.commons.pool.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:782)
... 4 more
I tries many ways ,the result keep the same.
I also run the class on the computer on oracle9i in home.
The same exception happened.
I don't know why.
The following is my code to test ojb.
First this is not a single-thread code.
It result in the same exception.
for (int i = 0; i 500;i++)
{
try
{
MyTest t_Test = new MyTest();
PersistenceBroker broker =
PersistenceBrokerFactory.defaultPersistenceBroker();
broker.beginTransaction();
broker.store(t_Test);
broker.commitTransaction();
System.out.println(
PersistenceBrokerFactoryFactory.instance().activePersistenceBroker());
//It keeps increasing and never decreasing.
//just like 1,2,3,and so on
}
catch (Exception e)
{
e.printStackTrace();
}
}
The following is a multi-thread code to test ojb.
List t_Threads = new ArrayList();
for (int i = 0; i 500; i++)
{
Thread t_Thread = new Thread()
{
public void run()
{
MyTest t_Test = new MyTest();
PersistenceBroker broker =
PersistenceBrokerFactory.defaultPersistenceBroker();
broker.beginTransaction();
broker.store(t_Test);
broker.commitTransaction();
System.err.println(
PersistenceBrokerFactoryFactory.instance().activePersistenceBroker());
//It keeps increasing and never decreasing.
//just like 1,2,3,and so on
}
};
t_Threads.add(t_Thread);
}
for (int i = 0; i t_Threads.size(); i++)
{
Thread t_Thread = (Thread) t_Threads.get(i);
t_Thread.start();
}
Is there anybody can provider a solution to me,
Thanks much.
_
MSN Hotmail http://www.hotmail.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: P6Spy config
Martin, Can you elaborate on this a bit? Why does the change in location of spy.properties solve the problem? Should deregister work on its own? Also, would a similar consideration apply if Tomcat is using a JDBC-based realm? I've never had any luck getting p6spy to work with Tomcat, and this sounds like it might help - we don't use load-on-startup, but we do have JDBC realm. thanks, -steve Steve Clark ECOS Development Group [EMAIL PROTECTED] (970)226-9291 Martin Kalén [EMAIL PROTECTED] 05/18/2005 07:39 PM Please respond to OJB Users List ojb-user@db.apache.org To OJB Users List ojb-user@db.apache.org cc Subject Re: P6Spy config Charles Anthony wrote: Just a note on p6spy which may, or may not, be relevant : I've often had problems with processes finding the p6spy.properties file - it always seems to work for me if the file is in the current directory when the process starts. So, for tomcat, for example, it seems to read the file from jakarta-tomcat-blah\bin It *doesn't* seem to be read from the classpath. This is not definitive, just something I recall from the dusty dank archives of my brain. Please treat with the appropriate amount of disdain. Another catch-all failure of getting P6Spy to work under Tomcat is if a servlet with load-on-startup=1 registers the standard JDBC driver before the application/servlet with P6 is loaded. In this scenario one has to make sure that spy.properties is in CATALINA_HOME/common/classes and that p6spy.jar is in CATALINA_HOME/common/lib (as opposed to WEB-INF/classes and WEB-INF/lib respectively). Then it's also important to have the deregister directive in spy.properties set to true so that P6 first de-registers the already loaded JDBC driver from DriverManager before registering it's own one. I guess these pieces of info should be a good start for a FAQ entry some day. ;) Cheers, Martin - 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: Bug: Proxy materialization with ODMG
Armin,
Good call. I was pretty sure it wasn't a concurrency issue, but there's a
long-forgotten daemon thread that's pre-loading all of the Counties after
the servlet is initialized. The failure occurs if this thread isn't done
loading the Counties by the time the test starts running. I'm not going
to worry about it any more, since the chances of this happening in real
life are essentially nil.
thanks,
-steve
Steve Clark
ECOS Development Group
[EMAIL PROTECTED]
(970)226-9291
Armin Waibel [EMAIL PROTECTED]
05/19/2005 04:19 AM
Please respond to
OJB Users List ojb-user@db.apache.org
To
OJB Users List ojb-user@db.apache.org
cc
Subject
Re: Bug: Proxy materialization with ODMG
Hi Steve,
could it be a concurrency problem? The odmg-tx is registered as a
materialization listener for proxy objects. When the object will be
materialized the listener is notified and
TranactionImpl#afterMaterialization is called. This method checks if the
tx is open, then the materialized object is registered.
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
at java.lang.Thread.run(Thread.java:534)
Caused by: org.odmg.LockNotGrantedException: Locking failed for
gov.doi.tat.dataobjects.CountyDetailImpl{06055}, nested exception is:
[org.odmg.TransactionNotInProgressException: Transaction was not open,
call tx.begin() before perform action, current status is:
STATUS_NO_TRANSACTION]
at
org.apache.ojb.odmg.TransactionImpl.afterMaterialization(TransactionImpl.java:1050)
Think the problem occur when a different thread try to materialize the
proxy object while the odmg-tx is not completed, is in committing (on
completion the odmg-tx remove itself as listener from the proxy object).
Did you share persistent object instances in different threads?
regards,
Armin
[EMAIL PROTECTED] wrote:
I am encountering a bug which doesn't quite happen reliably, but happens
about 75% of the time. The context is pretty large, so I'm going to
just
describe what's going on and see if anybody has any thoughts before I
try
to encapsulate it into a test case.
I'm using 1.0.3, ODMG, and the two-level cache. Most of my objects are
proxied; I don't use collection proxies.
I have a Transaction inside which, among other things, I make calls
which
sometimes result in proxy materialization. The code looks something
like
this:
tx.begin();
if (! tx.isOpen()) LOGGER.error(*** Transaction is not open!!!);
Collection res = profile.getUtmZones();
if (res == null) {
res = new HashSet();
Iterator iter = profile.getCounties().iterator();
while (iter.hasNext()) {
CountyDetail cd = ((County) iter.next()).getDetail();
if (! tx.isOpen()) LOGGER.error(*** Mid-scan: Transaction
is
not open!!!);
res.addAll(cd.getUtmZones());
}
}
...
tx.commit();
In my test case, the getCounties() list has 40+ entries; each county has
only a single UtmZone. Sometimes, the code runs to completion, and I
end
up with the correct contents in res. Other times, it throws the
following
Exception after processing a few (about a dozen) of the counties:
19:39:22,399 ERROR [] odmg.TransactionImpl (TransactionImpl.java:280) -
Unexpected failure while locking
org.odmg.TransactionNotInProgressException: Transaction was not open,
call
tx.begin() before perform action, current status is:
STATUS_NO_TRANSACTION
at
org.apache.ojb.odmg.TransactionImpl.checkOpen(TransactionImpl.java:188)
at
org.apache.ojb.odmg.TransactionImpl.getBroker(TransactionImpl.java:1115)
at
org.apache.ojb.odmg.ObjectEnvelope.getBroker(ObjectEnvelope.java:116)
at
org.apache.ojb.odmg.ObjectEnvelope.refreshObjectImage(ObjectEnvelope.java:174)
at
org.apache.ojb.odmg.ObjectEnvelope.init(ObjectEnvelope.java:110)
at
org.apache.ojb.odmg.ObjectEnvelopeTable.get(ObjectEnvelopeTable.java:420)
at
org.apache.ojb.odmg.TransactionImpl.register(TransactionImpl.java:884)
at
org.apache.ojb.odmg.TransactionImpl.lockAndRegister(TransactionImpl.java:267)
at
org.apache.ojb.odmg.TransactionImpl.afterMaterialization(TransactionImpl.java:1045)
at
org.apache.ojb.broker.core.proxy.IndirectionHandlerDefaultImpl.afterMaterialization(IndirectionHandlerDefaultImpl.java:176)
at
org.apache.ojb.broker.core.proxy.IndirectionHandlerDefaultImpl.getRealSubject(IndirectionHandlerDefaultImpl.java:349)
at
org.apache.ojb.broker.core.proxy.IndirectionHandlerDefaultImpl.invoke(IndirectionHandlerDefaultImpl.java:324)
at $Proxy4.getUtmZones(Unknown Source)
at
gov.doi.tat.dao.odmg.OfficeProfileDaoImpl.getUtmZones(OfficeProfileDaoImpl.java:813)
This
RE: Using user defined Collections
According to the error message, OJB is trying to set a field whose type is DatedList (target field type) with a value which is a RemovalAwareCollection (object value class). This is probably because you aren't setting collection-class in the collection-descriptor. In 1.0.2, AFAIK RemovalAwareCollection is still the default class used when collection-class isn't set, so OJB creates a RemovalAwareCollection to hold the retrieved elements and then tries to put it into your DatedList attribute, which fails. Setting collection-class=...DatedList should solve the problem. -steve Steve Clark ECOS Development Group [EMAIL PROTECTED] (970)226-9291 Lemke, Wesley [EMAIL PROTECTED] 05/18/2005 08:58 AM Please respond to OJB Users List ojb-user@db.apache.org To OJB Users List ojb-user@db.apache.org, Thomas Dudziak [EMAIL PROTECTED] cc Subject RE: Using user defined Collections I am still getting this error: [5/18/05 9:57:20:166 CDT] 74345b16 SystemOut O [PersistentField] ERROR: while set field: [try to set 'object value' in 'target object' target obj class: com.lmig.pm.affinity.model.client.account.AccountTeam target field name: accountManagers target field type: class com.lmig.pm.affinity.util.DatedList target field declared in: com.lmig.pm.affinity.model.client.account.AccountTeam object value class: org.apache.ojb.broker.util.collections.RemovalAwareCollection object value: [null(N010)] ] I have tried to extend bot ManageableArrayList and RemovalAwareList. Both give the same error. I am using OJB 1.0.2. Any other ideas? -Original Message- From: Thomas Dudziak [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 18, 2005 1:29 AM To: OJB Users List Subject: Re: Using user defined Collections Because we are subclassing from ArrayList, I didn't think that we would need to use the collection-class attribute of the collection-descriptor or implement ManageableCollection. Is this true? Nope, if you want OJB to create DatedList objects and initialize the properties with it, you'll have to implement ManageableCollection. The easiest way is probably to extend ManageableArrayList (OJB 1.0.3) or TrackingListImpl (OJB 1.1) instead of ArrayList directly. Also in this case, you should not need to specify collection-class if you declare the collection fields with this type. Tom - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Bug: Proxy materialization with ODMG
I am encountering a bug which doesn't quite happen reliably, but happens
about 75% of the time. The context is pretty large, so I'm going to just
describe what's going on and see if anybody has any thoughts before I try
to encapsulate it into a test case.
I'm using 1.0.3, ODMG, and the two-level cache. Most of my objects are
proxied; I don't use collection proxies.
I have a Transaction inside which, among other things, I make calls which
sometimes result in proxy materialization. The code looks something like
this:
tx.begin();
if (! tx.isOpen()) LOGGER.error(*** Transaction is not open!!!);
Collection res = profile.getUtmZones();
if (res == null) {
res = new HashSet();
Iterator iter = profile.getCounties().iterator();
while (iter.hasNext()) {
CountyDetail cd = ((County) iter.next()).getDetail();
if (! tx.isOpen()) LOGGER.error(*** Mid-scan: Transaction is
not open!!!);
res.addAll(cd.getUtmZones());
}
}
...
tx.commit();
In my test case, the getCounties() list has 40+ entries; each county has
only a single UtmZone. Sometimes, the code runs to completion, and I end
up with the correct contents in res. Other times, it throws the following
Exception after processing a few (about a dozen) of the counties:
19:39:22,399 ERROR [] odmg.TransactionImpl (TransactionImpl.java:280) -
Unexpected failure while locking
org.odmg.TransactionNotInProgressException: Transaction was not open, call
tx.begin() before perform action, current status is: STATUS_NO_TRANSACTION
at
org.apache.ojb.odmg.TransactionImpl.checkOpen(TransactionImpl.java:188)
at
org.apache.ojb.odmg.TransactionImpl.getBroker(TransactionImpl.java:1115)
at
org.apache.ojb.odmg.ObjectEnvelope.getBroker(ObjectEnvelope.java:116)
at
org.apache.ojb.odmg.ObjectEnvelope.refreshObjectImage(ObjectEnvelope.java:174)
at
org.apache.ojb.odmg.ObjectEnvelope.init(ObjectEnvelope.java:110)
at
org.apache.ojb.odmg.ObjectEnvelopeTable.get(ObjectEnvelopeTable.java:420)
at
org.apache.ojb.odmg.TransactionImpl.register(TransactionImpl.java:884)
at
org.apache.ojb.odmg.TransactionImpl.lockAndRegister(TransactionImpl.java:267)
at
org.apache.ojb.odmg.TransactionImpl.afterMaterialization(TransactionImpl.java:1045)
at
org.apache.ojb.broker.core.proxy.IndirectionHandlerDefaultImpl.afterMaterialization(IndirectionHandlerDefaultImpl.java:176)
at
org.apache.ojb.broker.core.proxy.IndirectionHandlerDefaultImpl.getRealSubject(IndirectionHandlerDefaultImpl.java:349)
at
org.apache.ojb.broker.core.proxy.IndirectionHandlerDefaultImpl.invoke(IndirectionHandlerDefaultImpl.java:324)
at $Proxy4.getUtmZones(Unknown Source)
at
gov.doi.tat.dao.odmg.OfficeProfileDaoImpl.getUtmZones(OfficeProfileDaoImpl.java:813)
This is all currently inside a WebApp, so it's a bit difficult to
perfectly control the test environment. But my test methodology is to
shut down Tomcat, start it up, and then go directly to the page which
causes the error, so that it is the first page view in a fresh run.
'profile' is always the same object, and profile.getUtmZones() always
returns null. This is the situation in which the code sometimes runs to
completion and sometimes does not.
More info:
Profile.counties is a collection of proxied County's
County.detail is a proxied CountyDetail
County.utmZones is a collection of proxied UtmZone's
OfficeProfileDaoImpl.java:813 (the point at which the stack trace calls
into OJB) is the res.addAll() line in the above code snippet
The Mid-scan: Transaction is not open message is not printed, so I
assume that before I call getUtmZones(), I am in a valid Transaction
I have tried adding additional logging statements inside the loop. If
they look at the proxied objects at all, the location of the error
changes, but the same error occurs (i.e., some other proxied object fails
to be locked because of STATUS_NO_TRANSACTION)
I have tried catching the PBException and examining the Transaction at
that point. tx.isOpen() still returns true, and
Implementation.currentTransaction() is still == tx
So I guess that it seems as if the proxy materialization is somehow
calling back to some other Transaction that is no longer active. Anybody
have any ideas on this?
thanks,
-steve
Steve Clark
ECOS Development Group
[EMAIL PROTECTED]
(970)226-9291
PS: For completeness, here's the entire stack trace once it gets wrapped
as a PBException:
org.apache.ojb.broker.PersistenceBrokerException: Error invoking method
getUtmZones
at
org.apache.ojb.broker.core.proxy.IndirectionHandlerDefaultImpl.invoke(IndirectionHandlerDefaultImpl.java:334)
at $Proxy4.getUtmZones(Unknown Source)
at
OJB 1.0.3 bug (with test case): Two m:n collections between same pair of classes
We have encountered another bug in 1.0.3. We are using ODMG, though I
suspect this one is a PB bug. It also looks like it's related to the
problem reported last week by Bartomiej Knabel ([PB] two relations
between two classes).
Summary: I have a class Parent which has two separate m:n relationships
to the same class Child. All entries for both relationships are always
written to the indirection table for the first one that appears in
repository.xml - nothing is ever written to the second indirection table.
If I put entries in both indirection tables by hand, then the object is
materialized correctly.
Here's a test case:
OjbTest.java
package ojbtest;
import java.util.ArrayList;
import java.util.List;
import junit.framework.Assert;
import junit.framework.Test;
import junit.framework.TestCase;
import org.apache.ojb.odmg.OJB;
import org.odmg.Database;
import org.odmg.Implementation;
import org.odmg.OQLQuery;
import org.odmg.Transaction;
public class OjbTest extends TestCase {
private Implementation fImplementation = null;
private Database fDatabase = null;
public OjbTest() { }
public void testTwoMToNOfSameClass()
throws Exception
{
Transaction tx = fImplementation.newTransaction();
tx.begin();
Parent parent = new Parent(1);
fDatabase.makePersistent(parent);
Child child = new Child(20);
fDatabase.makePersistent(child);
List list = new ArrayList();
list.add(child);
parent.setChildren(list);
child = new Child(30);
fDatabase.makePersistent(child);
list = new ArrayList();
list.add(child);
parent.setOtherChildren(list);
tx.commit();
// Make sure that DO's are built correctly
Assert.assertEquals(1, parent.getChildren().size());
Assert.assertEquals(20, ((Child)
parent.getChildren().get(0)).getId());
Assert.assertEquals(1, parent.getOtherChildren().size());
Assert.assertEquals(30, ((Child)
parent.getOtherChildren().get(0)).getId());
// Retrieve the parent and see what we get
tx = fImplementation.newTransaction();
tx.begin();
OQLQuery query = fImplementation.newOQLQuery();
query.create(select x from ojbtest.Parent where id = 1);
parent = (Parent) ((List) query.execute()).get(0);
Assert.assertEquals(1, parent.getChildren().size());
Assert.assertEquals(20, ((Child)
parent.getChildren().get(0)).getId());
Assert.assertEquals(1, parent.getOtherChildren().size());
Assert.assertEquals(30, ((Child)
parent.getOtherChildren().get(0)).getId());
tx.commit();
}
protected void setUp()
throws Exception
{
super.setUp();
if (fImplementation == null) {
fImplementation = OJB.getInstance();
fDatabase = fImplementation.newDatabase();
fDatabase.open(tails, fDatabase.OPEN_READ_WRITE);
}
}
}
Parent.java
package ojbtest;
import java.util.List;
public class Parent {
private int fId;
private List fChildren;
private List fOtherChildren;
public Parent() { }
public Parent(int id) { fId = id; }
public void setId(int id) { fId = id; }
public int getId() { return fId; }
public void setChildren(List list) { fChildren = list; }
public List getChildren() { return fChildren; }
public void setOtherChildren(List list) { fOtherChildren = list; }
public List getOtherChildren() { return fOtherChildren; }
}
Child.java
package ojbtest;
import java.util.List;
public class Child {
private int fId;
public Child() { }
public Child(int id) { fId = id; }
public void setId(int id) { fId = id; }
public int getId() { return fId; }
}
repository_user.xml
!-- - - - - - - Parent - - - - - - --
class-descriptor
class=ojbtest.Parent
table=PARENT
field-descriptor
name=id
column=ID
jdbc-type=INTEGER
primarykey=true
/
object-cache
class=org.apache.ojb.broker.cache.ObjectCachePerBrokerImpl /
collection-descriptor
name=children
element-class-ref=ojbtest.Child
indirection-table=PARENT_CHILD
auto-delete=none
auto-update=none
fk-pointing-to-this-classcolumn=PARENT_ID /
fk-pointing-to-element-class column=CHILD_ID /
/collection-descriptor
collection-descriptor
name=otherChildren
element-class-ref=ojbtest.Child
indirection-table=OTHER_PARENT_CHILD
auto-delete=none
auto-update=none
fk-pointing-to-this-classcolumn=PARENT_ID /
fk-pointing-to-element-class column=CHILD_ID /
/collection-descriptor
/class-descriptor
!-- - - - - -
Is ODMG usable in 1.0.3?
I'm still having trouble with the collection stuff I asked about last week, and now a new problem: I use anonymous keys for essentially all of my references. With the required-for-ODMG setting of auto-update=none, it appears that OJB never sets the anonymous keys from the values in the referenced objects: It is always inserting null into the FK column. Should I just give up on 1.0.3, or am I missing something? -steve Steve Clark ECOS Development Group [EMAIL PROTECTED] (970)226-9291 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is ODMG usable in 1.0.3?
Armin,
Here's what we know so far about the anonymous key problems:
1:1 reference: Creating a new parent object and linking to an existing
child object, the FK is correctly set only if we call makePersistent() on
the parent object after the reference is established; if makePersistent()
is called before the reference is established, then the FK does not get
set::
// this case fails
tx.begin();
parent = new Parent();
db.makePersistent(parent);
child = findChild();
parent.setChild(child);
tx.commit();
// this case works
tx.begin();
parent = new Parent();
child = findChild();
parent.setChild(child);
db.makePersistent(parent);
tx.commit();
1:1 reference: Updating an existing parent object and linking to an
existing child object, the FK does not get set
m:n collection: Create a new parent object and link to a new child object,
the FK does not get set
Both cases: If we set auto-update=link, the FK is correctly set
(regardless of when makePersistent() is called in the 1:1 case)
We have not tested with non-anonymous keys
I will try the patch and see what happens, and will also try to get some
data on the non-anonymous key behavior.
thanks,
-steve
Steve Clark
ECOS Development Group
[EMAIL PROTECTED]
(970)226-9291
Armin Waibel [EMAIL PROTECTED]
05/03/2005 11:22 AM
Please respond to
OJB Users List ojb-user@db.apache.org
To
OJB Users List ojb-user@db.apache.org
cc
Subject
Re: Is ODMG usable in 1.0.3?
Hi Steve,
[EMAIL PROTECTED] wrote:
I'm still having trouble with the collection stuff I asked about last
week, and now a new problem:
I use anonymous keys for essentially all of my references.
Do you use it for all 1:1 references or generally in all references?
With the
required-for-ODMG setting of auto-update=none, it appears that OJB
never
sets the anonymous keys from the values in the referenced objects: It is
always inserting null into the FK column.
Are you sure that all anonymous keys be ignored or only these in
conjunction with 1:n relations? If the FK wasn't anonymous the test pass?
I ask because there is a bug in handling of new n-side objects of 1:n
relations. The linking for new objects is not done. But this is
independent of the field type (anonymous on/off).
Please try to patch ObjectEnvelopeTable#cascadeInsertCollectionReferences
in line 666 replace
else
{
// we mark collection reference for linking
oe.addLinkOneToN(col, source.getObject(), false);
}
with
else
{
// we mark collection reference for linking
oe.addLinkOneToN(col, source.getObject(), false);
oe.setModificationState(oe.getModificationState().markDirty());
}
This should fix problems with new added objects in 1:n relations.
Should I just give up on 1.0.3, or am I missing something?
I'm strongly interested in fixing all issues in odmg. The problem is
that I can only run against the OJB test-suite (all these tests pass for
1.0.3). Please report all issues to jira if possible with some kind of
test case to reproduce the bug. I will try to fix this stuff till next
release.
regards,
Armin
-steve
Steve Clark
ECOS Development Group
[EMAIL PROTECTED]
(970)226-9291
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is ODMG usable in 1.0.3?
So many projects, so few brain cells.
The problem with setting FK's is not in 1.0.3, it's in 1.0.0. Version
problem on my end, and now I really have upgraded in this project.
Mea maxima culpa.
Last week's collection stuff still stands, though (Armin, did you get my
test case?).
-steve
Steve Clark
ECOS Development Group
[EMAIL PROTECTED]
(970)226-9291
Armin Waibel [EMAIL PROTECTED]
05/03/2005 11:22 AM
Please respond to
OJB Users List ojb-user@db.apache.org
To
OJB Users List ojb-user@db.apache.org
cc
Subject
Re: Is ODMG usable in 1.0.3?
Hi Steve,
[EMAIL PROTECTED] wrote:
I'm still having trouble with the collection stuff I asked about last
week, and now a new problem:
I use anonymous keys for essentially all of my references.
Do you use it for all 1:1 references or generally in all references?
With the
required-for-ODMG setting of auto-update=none, it appears that OJB
never
sets the anonymous keys from the values in the referenced objects: It is
always inserting null into the FK column.
Are you sure that all anonymous keys be ignored or only these in
conjunction with 1:n relations? If the FK wasn't anonymous the test pass?
I ask because there is a bug in handling of new n-side objects of 1:n
relations. The linking for new objects is not done. But this is
independent of the field type (anonymous on/off).
Please try to patch ObjectEnvelopeTable#cascadeInsertCollectionReferences
in line 666 replace
else
{
// we mark collection reference for linking
oe.addLinkOneToN(col, source.getObject(), false);
}
with
else
{
// we mark collection reference for linking
oe.addLinkOneToN(col, source.getObject(), false);
oe.setModificationState(oe.getModificationState().markDirty());
}
This should fix problems with new added objects in 1:n relations.
Should I just give up on 1.0.3, or am I missing something?
I'm strongly interested in fixing all issues in odmg. The problem is
that I can only run against the OJB test-suite (all these tests pass for
1.0.3). Please report all issues to jira if possible with some kind of
test case to reproduce the bug. I will try to fix this stuff till next
release.
regards,
Armin
-steve
Steve Clark
ECOS Development Group
[EMAIL PROTECTED]
(970)226-9291
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: problem with lists in n:m relation and proxy=dynamic
You need to implement equals() in your Pharmacy implementation class.
What's happening is that either the object in the collection or the object
that you're passing to remove() is a Proxy. The default implementation of
equals() (which is used by remove()) just uses ==. Since the objects are
not the same object, remove() doesn't find the one you're trying to get
rid of.
Here's a sample implementation (for a PharmacyImpl class implementing a
Pharmacy interface - adjust names as necessary):
public boolean equals(Object o) {
if (o == null) return false;
if (o == this) return true;
// Double-dispatch to remove any Proxy from the picture
if (java.lang.reflect.Proxy.isProxyClass(o.getClass())) {
return o.equals(this);
}
if (! getClass().equals(o.getClass())) return false;
PharmacyImpl p = (PharmacyImpl) o;
// compare two PharmacyImpl's this and p
}
Also, be sure to implement hashCode() as well. It needs to return a value
which is consistent with equals() - i.e. two objects which are equals()
should have the same hashCode().
-steve
Steve Clark
ECOS Development Group
[EMAIL PROTECTED]
(970)226-9291
Günther Wieser [EMAIL PROTECTED]
05/02/2005 04:15 AM
Please respond to
OJB Users List ojb-user@db.apache.org
To
'OJB Users List' ojb-user@db.apache.org
cc
Subject
problem with lists in n:m relation and proxy=dynamic
hi,
i've two classes that are linked to each other (bi-directional) using an
indeirection table. they are called pharmacy and campaign, and
pharmacy
has a method List getCampaigns() to retreive all campaigns it is in, and
campaign has a method List getPharmacies(), which gives back the list of
pharmacies that participate in this campaign.
when i need to remove one pharmacy from a campaign, i do the following:
boolean campRemoveResult = campaign.getPharmacies().remove(pharmacy);
boolean pharmRemoveResult = pharmacy.getCampaigns().remove(campaign);
then i store both of the them to have my changes persistet. i can see in
the
database that the entry in the indirection table has beem removed.
BUT: pharmRemoveResult is TRUE, but campRemoveResult = FALSE, and the list
campaign.getPharmacies() still contains the pharmacy i just removed.
so far i found out that the pharmacy object linked to the list in campaign
is somehow different to the pharmacy object i have during runtime. if i do
a
toString() on the pharmacy i have and the pharmacy i found in the pharmacy
list of camaign (searched for the same primary key), the both have the
same
object id and all the values AND references to other objects are the same.
still, the equals() method returns false.
pharmacy has proxy=dynamic, and if i remove this, everything works fine.
but this is of course no solution for my problem.
anyone an idea how to successfully remove objects from a list if the only
object that should be removed has proxy=dynamic? am i doing something
fundamentally wrong here?
kr,
guenther
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems with collections in ODMG - just upgraded to OJB 1.0.3
Martin Armin, Thanks for the responses. Some more info: - The collection in question is a non-decomposed m:n. - There actually are two collections which exhibit this problem; in one case the child pk is an int, and in the other it's a String. The keys are not null or 0 (the child being added was retrieved by pk, and in the log file the error message for the INSERT statement shows the expected pk value - the way that I found the problem is that the INSERT fails because it violates the pk constraint). - In one case, the child is proxyable; in the other case, it is not. - I have tried using the default auto-xxx settings and also explicitly setting auto-delete and auto-update=none. - The child has accept-locks=false. Here's a repository.xml snippet: !-- - - - - - - FieldOfficeProfile - - - - - - -- class-descriptor class=gov.doi.tat.dataobjects.FieldOfficeProfileImpl table=FIELD_OFFICE_PROFILE factory-method=createFieldOfficeProfile factory-class=gov.doi.tat.dataobjects.SupportDOFactory field-descriptor name=officeId nullable=false column=OFFICE_ID jdbc-type=INTEGER primarykey=true / !-- Collections -- collection-descriptor name=counties element-class-ref=gov.doi.tat.dataobjects.County indirection-table=FIELD_OFFICE_COUNTY auto-update=none auto-delete=none fk-pointing-to-this-classcolumn=OFFICE_ID / fk-pointing-to-element-class column=FIPS / /collection-descriptor collection-descriptor name=listedSpecies element-class-ref=gov.doi.tess.dataobjects.TessPopulation indirection-table=FIELD_OFFICE_SPECIES auto-update=none auto-delete=none fk-pointing-to-this-classcolumn=OFFICE_ID / fk-pointing-to-element-class column=ENTITY_ID / /collection-descriptor /class-descriptor !-- - - - - - - County - - - - - - -- class-descriptor class=gov.doi.tat.dataobjects.County schema=SUPPORT table=COUNTY_LUT accept-locks=false field-descriptor name=fullFips column=FIPS jdbc-type=VARCHAR primarykey=true / ... /class-descriptor !-- - - - - - - TessPopulation - - - - - - -- class-descriptor class=gov.doi.tess.dataobjects.TessPopulation extent-class class-ref=gov.doi.tess.dataobjects.TessPopulationImpl / /class-descriptor class-descriptor class=gov.doi.tess.dataobjects.TessPopulationImpl factory-class=gov.doi.tess.dataobjects.TessDOFactory factory-method=createTessPopulation schema=TESS table=SPECIES_DETAILS accept-locks=false field-descriptor name=entityId column=ENTITY_ID jdbc-type=INTEGER primarykey=true / ... /class-descriptor Code snippet:: county = getCountyByFips(fips); tx = odmg.newTransaction(); profile = new FieldOfficeProfileImpl(); database.makePersistent(profile); profile.addCounty(county); tx.commit(); thanks, -steve Steve Clark ECOS Development Group [EMAIL PROTECTED] (970)226-9291 Armin Waibel [EMAIL PROTECTED] 04/28/2005 04:12 AM Please respond to OJB Users List ojb-user@db.apache.org To OJB Users List ojb-user@db.apache.org cc Subject Re: Problems with collections in ODMG - just upgraded to OJB 1.0.3 Hi Steve, [EMAIL PROTECTED] wrote: Now I remember why I'm always hesitant to upgrade OJB - it seems like there is some fundamental change to how things work. we made a complete refactoring of the odmg implementation in 1.0.2/3, because of the many known issues in OJB =1.0.1 (see release-notes 1.0.2/3). I did my best not to break backward compatibility. The problem is that we don't get much feedback from the ODMG users, so I only can test against the OJB test-suite which never could reflect behavior of a real OJB application. Major changes are noted in release-notes. But you are right, internally the odmg implementation changed (better dirty-detection, avoid of materialization proxy objects, ...). I hope things are getting more stable, 'cause in the in-between times when I don't have to rework, it's a great tool. My intention was to make it more stable ;-) Here's where I'm stuck now. I just upgraded from 1.0.0 to 1.0.3; I use the ODMG API. I have the following pseudo-code: child = retrieveSomeObjectFromDatabase(); tx = odmg.newTransaction(); parent = new Parent(); database.makePersistent(parent); parent.addChild(child); tx.commit(); parent.addChild() does what it sounds like: calls children.add(child). When I commit the transaction, OJB tries to insert a new Child. Can anybody tell me why this might happen? This is, obviously, a showstopper for me. It happens with default caching (i.e. none) and with the
Re: Problems with collections in ODMG - just upgraded to OJB 1.0.3
Three more things:
1) I have ImplicitLocking turned off
2) My pseudocode is wrong: Actually, the parent object is created in a
different transaction. So it's like this:
tx = odmg.newTransaction();
profile = new FieldOfficeProfileImpl();
database.makePersistent(profile);
tx.commit();
tx = odmg.newTransaction();
// Following line does not change behavior:
// profile = getProfileById(profileId);
county = getCountyByFips(fips);
profile.addCounty(county);
tx.commit();
3) According to the log file, county is indeed getting registered as new
dirty:
DEBUG [main] (TransactionImpl.java:316) - Do WRITE lock on object:
gov.doi.tat.dataobjects.FieldOfficeProfileImpl{64542}
DEBUG [main] (LockManagerInMemoryImpl.java:292) -
LM.writeLock(tx-10.100.182.239:83e1e:10389c5d682:-7fff,
gov.doi.tat.dataobjects.FieldOfficeProfileImpl{64542})
DEBUG [main] (ObjectEnvelopeTable.java:424) - register:
[EMAIL PROTECTED],ModificationState=org.apache.ojb.odmg.states.StateOldClean]
DEBUG [main] (TransactionImpl.java:362) - call beginTransaction() on PB
instance
DEBUG [main] (ConnectionManagerImpl.java:170) - localBegin was called for
con [EMAIL PROTECTED]
DEBUG [main] (ConnectionManagerImpl.java:173) - Try to change autoCommit
state to 'false'
DEBUG [main] (ObjectEnvelopeTable.java:143) - PB is in internal tx: true
broker was: [EMAIL PROTECTED]
DEBUG [main] (ObjectEnvelopeTable.java:424) - register:
[EMAIL PROTECTED],ModificationState=org.apache.ojb.odmg.states.StateNewDirty]
thanks,
-steve
Steve Clark
ECOS Development Group
[EMAIL PROTECTED]
(970)226-9291
[EMAIL PROTECTED]
04/28/2005 09:54 AM
Please respond to
OJB Users List ojb-user@db.apache.org
To
OJB Users List ojb-user@db.apache.org
cc
Subject
Re: Problems with collections in ODMG - just upgraded to OJB 1.0.3
Martin Armin,
Thanks for the responses. Some more info:
- The collection in question is a non-decomposed m:n.
- There actually are two collections which exhibit this problem; in one
case the child pk is an int, and in the other it's a String. The keys are
not null or 0 (the child being added was retrieved by pk, and in the log
file the error message for the INSERT statement shows the expected pk
value - the way that I found the problem is that the INSERT fails because
it violates the pk constraint).
- In one case, the child is proxyable; in the other case, it is not.
- I have tried using the default auto-xxx settings and also explicitly
setting auto-delete and auto-update=none.
- The child has accept-locks=false.
Here's a repository.xml snippet:
!-- - - - - - - FieldOfficeProfile - - - - - - --
class-descriptor
class=gov.doi.tat.dataobjects.FieldOfficeProfileImpl
table=FIELD_OFFICE_PROFILE
factory-method=createFieldOfficeProfile
factory-class=gov.doi.tat.dataobjects.SupportDOFactory
field-descriptor
name=officeId
nullable=false
column=OFFICE_ID
jdbc-type=INTEGER
primarykey=true
/
!-- Collections --
collection-descriptor
name=counties
element-class-ref=gov.doi.tat.dataobjects.County
indirection-table=FIELD_OFFICE_COUNTY
auto-update=none
auto-delete=none
fk-pointing-to-this-classcolumn=OFFICE_ID /
fk-pointing-to-element-class column=FIPS /
/collection-descriptor
collection-descriptor
name=listedSpecies
element-class-ref=gov.doi.tess.dataobjects.TessPopulation
indirection-table=FIELD_OFFICE_SPECIES
auto-update=none
auto-delete=none
fk-pointing-to-this-classcolumn=OFFICE_ID /
fk-pointing-to-element-class column=ENTITY_ID /
/collection-descriptor
/class-descriptor
!-- - - - - - - County - - - - - - --
class-descriptor
class=gov.doi.tat.dataobjects.County
schema=SUPPORT
table=COUNTY_LUT
accept-locks=false
field-descriptor
name=fullFips
column=FIPS
jdbc-type=VARCHAR
primarykey=true
/
...
/class-descriptor
!-- - - - - - - TessPopulation - - - - - - --
class-descriptor
class=gov.doi.tess.dataobjects.TessPopulation
extent-class
class-ref=gov.doi.tess.dataobjects.TessPopulationImpl /
/class-descriptor
class-descriptor
class=gov.doi.tess.dataobjects.TessPopulationImpl
factory-class=gov.doi.tess.dataobjects.TessDOFactory
factory-method=createTessPopulation
schema=TESS
table=SPECIES_DETAILS
accept-locks=false
field-descriptor
name=entityId
column=ENTITY_ID
jdbc-type=INTEGER
primarykey=true
/
...
/class-descriptor
Code snippet::
county = getCountyByFips(fips);
tx = odmg.newTransaction();
profile = new FieldOfficeProfileImpl();
database.makePersistent(profile);
profile.addCounty(county);
tx.commit();
thanks,
Re: Problems with collections in ODMG - just upgraded to OJB 1.0.3
Sigh. Is it still Monday? I'll get it right eventually. Here is what is
(was) actually being done:
tx = odmg.newTransaction();
tx.begin();
profile = new FieldOfficeProfileImpl();
database.makePersistent(profile);
tx.commit();
tx = odmg.newTransaction();
tx.begin();
// Following line does not change behavior:
// profile = getProfileById(profileId);
county = getCountyByFips(fips);
tx.lock(profile, tx.WRITE);
profile.addCounty(county);
tx.commit();
I tried adding tx.lock(county, tx.WRITE) and now it works, though I don't
understand why - county doesn't know about profile, and so is not being
changed. I've never had to lock the child in this situation before. And
it's pretty weird that if I don't lock it, OJB tries to insert it, and if
I do lock it, it doesn't try to insert it!
Moving on, I find the same behavior with delete - when I delete a county
from a profile, I now have to lock the county as well as the profile; in
this case, though, at least the error message tells me what the problem is
(unregistered object found for delete).
I guess this is something that has changed as a result of the ODMG
refactoring? As Martin said, it would be great if release notes could
address this sort of basic change (heck, maybe I was relying on buggy
behavior without realizing it, and it's my own fault).
In any case, thanks for the great tool and the troubleshooting help.
-steve
Steve Clark
ECOS Development Group
[EMAIL PROTECTED]
(970)226-9291
Armin Waibel [EMAIL PROTECTED]
04/28/2005 11:50 AM
Please respond to
OJB Users List ojb-user@db.apache.org
To
OJB Users List ojb-user@db.apache.org
cc
Subject
Re: Problems with collections in ODMG - just upgraded to OJB 1.0.3
[EMAIL PROTECTED] wrote:
Three more things:
1) I have ImplicitLocking turned off
2) My pseudocode is wrong: Actually, the parent object is created in a
different transaction. So it's like this:
tx = odmg.newTransaction();
profile = new FieldOfficeProfileImpl();
database.makePersistent(profile);
tx.commit();
tx = odmg.newTransaction();
// Following line does not change behavior:
// profile = getProfileById(profileId);
county = getCountyByFips(fips);
profile.addCounty(county);
tx.commit();
This is radical different! How should the second tx recognize the County
and the Profile objects? You set implicite locking off, so the Count
object is not locked and the Profile object too.
tx = odmg.newTransaction();
tx.begin();
// Following line does not change behavior:
// profile = getProfileById(profileId);
county = getCountyByFips(fips);
tx.lock(county, Transaction.WRITE);
tx.lock(profile, Transaction.WRITE);
profile.addCounty(county);
tx.commit();
3) According to the log file, county is indeed getting registered as
new
dirty:
This is strange, because when implicite locking is off no requested
objects should be locked/registered. Or does getProfileById lock the
requested objects?
regards,
Armin
DEBUG [main] (TransactionImpl.java:316) - Do WRITE lock on object:
gov.doi.tat.dataobjects.FieldOfficeProfileImpl{64542}
DEBUG [main] (LockManagerInMemoryImpl.java:292) -
LM.writeLock(tx-10.100.182.239:83e1e:10389c5d682:-7fff,
gov.doi.tat.dataobjects.FieldOfficeProfileImpl{64542})
DEBUG [main] (ObjectEnvelopeTable.java:424) - register:
[EMAIL PROTECTED],ModificationState=org.apache.ojb.odmg.states.StateOldClean]
DEBUG [main] (TransactionImpl.java:362) - call beginTransaction() on PB
instance
DEBUG [main] (ConnectionManagerImpl.java:170) - localBegin was called
for
con [EMAIL PROTECTED]
DEBUG [main] (ConnectionManagerImpl.java:173) - Try to change autoCommit
state to 'false'
DEBUG [main] (ObjectEnvelopeTable.java:143) - PB is in internal tx: true
broker was: [EMAIL PROTECTED]
DEBUG [main] (ObjectEnvelopeTable.java:424) - register:
[EMAIL PROTECTED],ModificationState=org.apache.ojb.odmg.states.StateNewDirty]
thanks,
-steve
Steve Clark
ECOS Development Group
[EMAIL PROTECTED]
(970)226-9291
[EMAIL PROTECTED]
04/28/2005 09:54 AM
Please respond to
OJB Users List ojb-user@db.apache.org
To
OJB Users List ojb-user@db.apache.org
cc
Subject
Re: Problems with collections in ODMG - just upgraded to OJB 1.0.3
Martin Armin,
Thanks for the responses. Some more info:
- The collection in question is a non-decomposed m:n.
- There actually are two collections which exhibit this problem; in one
case the child pk is an int, and in the other it's a String. The keys
are
not null or 0 (the child being added was retrieved by pk, and in the log
file the error message for the INSERT statement shows the expected pk
value - the way that I found the problem is that the INSERT fails
because
it violates the pk constraint).
- In one case, the child is proxyable; in the other case, it is not.
- I have tried
Problems with collections in ODMG - just upgraded to OJB 1.0.3
Now I remember why I'm always hesitant to upgrade OJB - it seems like there is some fundamental change to how things work. I hope things are getting more stable, 'cause in the in-between times when I don't have to rework, it's a great tool. Here's where I'm stuck now. I just upgraded from 1.0.0 to 1.0.3; I use the ODMG API. I have the following pseudo-code: child = retrieveSomeObjectFromDatabase(); tx = odmg.newTransaction(); parent = new Parent(); database.makePersistent(parent); parent.addChild(child); tx.commit(); parent.addChild() does what it sounds like: calls children.add(child). When I commit the transaction, OJB tries to insert a new Child. Can anybody tell me why this might happen? This is, obviously, a showstopper for me. It happens with default caching (i.e. none) and with the two-level cache. Other random ODMG questions: At some point, the instructions for adding a new persistent object using ODMG changed; I'm not sure when. It used to say that tx.lock(object, tx.WRITE) would add the object to the db if it wasn't already there, and this is how I've always done it. Now I see that the tutorial says to use db.makePersistent(object), and the code for the two is different. Will tx.lock() still work, or do I have to rewrite all of my DAOs? Is it true that the (unofficial) feature which actually did allow ODMG to observe auto-delete settings is gone? I've always (in OJB ODMG) used cascading delete bounded by appropriate auto-delete settings; now it looks as if I have no choice but to delete each individual object by hand. True? Setting the cascading delete settings by relationship type (1:1, 1:n, m:n) seems extremely weird, and certainly won't be very useful, since the correct delete semantics are always a function of the particular relationship, not of the form of the relationship. thanks, -steve Steve Clark ECOS Development Group [EMAIL PROTECTED] (970)226-9291 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
