Re: Crossreferenced Objects
I tried again to make it work all the day along,
When I retrieve objects in Junit test cases, it doesn't give me any
error with most of cache implementations...
If anyone have any Idea, I am realy thinking this case is hopeless.
Here is the full error stack :
java.lang.StackOverflowError
at java.lang.Integer.toString(Integer.java:296)
at java.lang.Integer.toString(Integer.java:109)
at java.lang.String.valueOf(String.java:2236)
at com.mysql.jdbc.PreparedStatement.setInt(PreparedStatement.java:558)
at
com.mysql.jdbc.PreparedStatement.setObject(PreparedStatement.java:772)
at
com.mysql.jdbc.PreparedStatement.setObject(PreparedStatement.java:944)
at
org.apache.ojb.broker.platforms.PlatformDefaultImpl.setObjectForStatement(PlatformDefaultImpl.java:249)
at
org.apache.ojb.broker.platforms.PlatformMySQLImpl.setObjectForStatement(PlatformMySQLImpl.java:87)
at
org.apache.ojb.broker.accesslayer.StatementManager.bindStatementValue(StatementManager.java:216)
at
org.apache.ojb.broker.accesslayer.StatementManager.bindStatement(StatementManager.java:248)
at
org.apache.ojb.broker.accesslayer.StatementManager.bindSelectionCriteria(StatementManager.java:424)
at
org.apache.ojb.broker.accesslayer.StatementManager.bindStatement(StatementManager.java:388)
at
org.apache.ojb.broker.accesslayer.StatementManager.bindStatement(StatementManager.java:361)
at
org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeQuery(JdbcAccessImpl.java:279)
at
org.apache.ojb.broker.accesslayer.RsQueryObject.performQuery(RsQueryObject.java:74)
at
org.apache.ojb.broker.accesslayer.RsIterator.(RsIterator.java:183)
at
org.apache.ojb.broker.core.RsIteratorFactoryImpl.createRsIterator(RsIteratorFactoryImpl.java:58)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getRsIteratorFromQuery(PersistenceBrokerImpl.java:1808)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getIteratorFromQuery(PersistenceBrokerImpl.java:1333)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getIteratorByQuery(PersistenceBrokerImpl.java:1320)
at
org.apache.ojb.broker.accesslayer.BasePrefetcher.prefetchRelationship(BasePrefetcher.java:104)
at
org.apache.ojb.broker.core.QueryReferenceBroker.performRetrievalTasks(QueryReferenceBroker.java:329)
at
org.apache.ojb.broker.accesslayer.BasePrefetcher.prefetchRelationship(BasePrefetcher.java:113)
at
org.apache.ojb.broker.core.QueryReferenceBroker.performRetrievalTasks(QueryReferenceBroker.java:329)
at
org.apache.ojb.broker.accesslayer.BasePrefetcher.prefetchRelationship(BasePrefetcher.java:113)
at
org.apache.ojb.broker.core.QueryReferenceBroker.performRetrievalTasks(QueryReferenceBroker.java:329)
at
org.apache.ojb.broker.accesslayer.BasePrefetcher.prefetchRelationship(BasePrefetcher.java:113)
(and so on...)
On Wed, 26 Jan 2005 09:22:39 +0900, Sylvain ~ <[EMAIL PROTECTED]> wrote:
> I forgot to mention thaht I use OJB 1.0.1.
>
>
> On Tue, 25 Jan 2005 22:51:09 +0900, Sylvain ~ <[EMAIL PROTECTED]> wrote:
> > I think the problems comes from the cache implementation I use,
> > because It used to work quite well with jUnit tests and Default Cache
> > Implementation, and in this situation there is only One thread so
> > there wasn't any "dirty read" problem.
> >
> > However, since I moved the application in Struts Actions Under tomcat,
> > I couldn't use the default Cache Implementation since it is not
> > thread-safe, and I got some errors with retrieved data. So, I thought
> > that using a thread-safe cache implementation such as
> > "ObjectCachePerBrokerImpl" could solve the problem, and by doing so I
> > solved the problems that used to happen, until I tried Crossreferenced
> > Objects...
> >
> > I think that the source of the problem can be that I don't have any
> > global cache, because I retrieve first the Room Object and the nested
> > collection in a Struts Action (that might be running it it's own
> > thread), and then on the users collection elements I try to get
> > information on rooms, and it runs on a different thread from the first
> > Action since it located in a different Action.
> >
> > So, I think that using a global cache which is thread-safe could solve
> > this issue, however there is only few documentation on caches
> > implementations in the cache package.
> >
> > As I read in the javadoc, it seems that ObjectCachePerClassImpl is a
> > global cache, but i don't know if it thread-safe at all.
> >
> > I retrieve Objects using this code :
> >
> > public StorableObject get(Class objectClass, Integer pk) {
> >PersistenceBroker broker = null;
> >Object result;
> >
> >Criteria crit = new Criteria();
> >crit.addEqualTo("pk",pk);
> >crit = criteraModificator(objectClass, crit);
> >
> >try {
> >broker = PersistenceBro
Compiling OJB_1_0_RELEASE fails since yesterday
Hi, this have been introduced in since 1.144.2.13 or 1.144.2.14 of the build.xml: $ sh bin/build.sh Buildfile: build.xml detect-jdk: environment-check: BUILD FAILED /home/cpesch/ojb-1.0.x-from-cvs/db-ojb/build.xml:101: The type doesn't support the nested "condition" element. Total time: 1 second -- Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem running under a SecurityManager
Hi All,
I've solved it. It was my fault. Under my restrictive security
configuration (-Djava.security.manager==myjava.policy) I forgot to give
these permissions:
permission java.util.PropertyPermission "*", "read,write";
permission java.lang.RuntimePermission "setIO";
The System.getProperties() needs to have the previous PropertyPermission
to be able to load all the properties. Also the RuntimePermission
"setIO" was required if redirecting the console (System.setOut)
The code that was throwing the Exception is the following, but no
security exception was on the stack trace.
public class LoggingConfiguration extends ConfigurationAbstractImpl {
...
...
...
protected void load() {
Logger bootLogger = LoggerFactory.getBootLogger();
// first we check whether the system property
// org.apache.ojb.broker.util.logging.Logger
// is set (or its alias LoggerClass which is deprecated)
ClassLoader contextLoader = ClassHelper.getClassLoader();
String loggerClassName = null;
_loggerClass = null;
properties= new Properties();
loggerClassName = getLoggerClass(System.getProperties());
-->_loggerConfigFile = getLoggerConfigFile(System.getProperties());<---
...
...
...
}
Sean C. McCarthy
Sean C. McCarthy wrote:
Hi,
I'm trying to debug this:
--
java.lang.ExceptionInInitializerError
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:219)
at org.apache.ojb.broker.util.ClassHelper.getClass(Unknown Source)
at org.apache.ojb.broker.util.ClassHelper.getClass(Unknown Source)
at
org.apache.ojb.broker.util.configuration.impl.ConfigurationAbstractImpl.getClass(Unknown
Source)
at
org.apache.ojb.broker.util.configuration.impl.ConfigurationAbstractImpl.getClass(Unknown
Source)
at
org.apache.ojb.broker.core.PersistenceBrokerFactoryFactory.init(Unknown
Source)
at
org.apache.ojb.broker.core.PersistenceBrokerFactoryFactory.(Unknown
Source)
at
org.apache.ojb.broker.PersistenceBrokerFactory.createPersistenceBroker(Unknown
Source)
...
...
...
Caused by: java.lang.NullPointerException
at
org.apache.ojb.broker.util.logging.LoggerFactoryImpl.getLogger(Unknown
Source)
at org.apache.ojb.broker.util.logging.LoggerFactory.getLogger(Unknown
Source)
at
org.apache.ojb.broker.core.PersistenceBrokerFactoryBaseImpl.(Unknown
Source)
... 77 more
---
The code runs fine with permission AllPermission but it fails to do
under the following configuration related to OJB:
// Java Policy
// For "JVM pre-1.4 access bug workaround die to
// restrictive security manager" Exception
permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
// Several other permissions
permission java.io.FilePermission "<>", "read";
permission java.util.PropertyPermission "*", "read";
permission java.lang.RuntimePermission "createClassLoader";
permission java.lang.RuntimePermission "getClassLoader";
permission java.lang.RuntimePermission "accessClassInPackage.*";
permission java.lang.RuntimePermission "defineClassInPackage.*";
permission java.lang.RuntimePermission "accessDeclaredMembers";
permission java.lang.RuntimePermission "getClassLoader";
I tried to pass the OJB-logging.properties file as a java property, but
it doesn't help.
I would say it is a policy configuration problem since it only happens
when the policy permissions are restricted. With AllPermission it runs
just fine.
I'm using sun-jvm 1.4.2_06 and OJB 1.0.1. I haven't been able to track
this down. Any information would be appreciated.
Sean C. McCarthy
-
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: Crossreferenced Objects
I forgot to mention thaht I use OJB 1.0.1.
On Tue, 25 Jan 2005 22:51:09 +0900, Sylvain ~ <[EMAIL PROTECTED]> wrote:
> I think the problems comes from the cache implementation I use,
> because It used to work quite well with jUnit tests and Default Cache
> Implementation, and in this situation there is only One thread so
> there wasn't any "dirty read" problem.
>
> However, since I moved the application in Struts Actions Under tomcat,
> I couldn't use the default Cache Implementation since it is not
> thread-safe, and I got some errors with retrieved data. So, I thought
> that using a thread-safe cache implementation such as
> "ObjectCachePerBrokerImpl" could solve the problem, and by doing so I
> solved the problems that used to happen, until I tried Crossreferenced
> Objects...
>
> I think that the source of the problem can be that I don't have any
> global cache, because I retrieve first the Room Object and the nested
> collection in a Struts Action (that might be running it it's own
> thread), and then on the users collection elements I try to get
> information on rooms, and it runs on a different thread from the first
> Action since it located in a different Action.
>
> So, I think that using a global cache which is thread-safe could solve
> this issue, however there is only few documentation on caches
> implementations in the cache package.
>
> As I read in the javadoc, it seems that ObjectCachePerClassImpl is a
> global cache, but i don't know if it thread-safe at all.
>
> I retrieve Objects using this code :
>
> public StorableObject get(Class objectClass, Integer pk) {
>PersistenceBroker broker = null;
>Object result;
>
>Criteria crit = new Criteria();
>crit.addEqualTo("pk",pk);
>crit = criteraModificator(objectClass, crit);
>
>try {
>broker = PersistenceBrokerFactory.defaultPersistenceBroker();
>QueryByCriteria query = new QueryByCriteria(objectClass, crit);
>result = broker.getObjectByQuery(query);
>
>} finally {
>if (broker != null)
>broker.close();
>}
>return (StorableObject)result;
>}
>
> Regards,
> Sylvain.
>
> On Tue, 25 Jan 2005 11:23:02 +0100, Armin Waibel <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > which version of OJB do you use?
> > Did you try the default ObjectCache implementation? Same result?
> > How does your code look like?
> >
> > regards,
> > Armin
> >
> > Sylvain ~ wrote:
> > > Hi,
> > >
> > > I'm trying to create crossreferenced objects, as specified in the
> > > Cache documentation :
> > >
> > > "It allows to perform circular lookups (as by crossreferenced
> > > objects) that would result in non-terminating loops without such a
> > > cache."
> > >
> > > I Use ObjectCachePerBrokerImpl since my application is multi-threaded
> > > (and runs on tomcat)
> > >
> > > The problem is that I get a java.lang.StackOverflowError, when trying
> > > to do so with theses classes (simplified for clarity). both classes
> > > have auto-retrieve="true".
> > >
> > > Any Idea to make it work would be appreciated.
> > > Sylvain.
> > >
> > > public class User {
> > >
> > >/**
> > >* --- PK ---
> > >* @ojb.field primarykey="true"
> > >* autoincrement="ojb"
> > >*/
> > > private Integer pk=null;
> > >
> > > /**
> > > * user room
> > > * @ojb.reference
> > > *foreignkey="pk"
> > > */
> > > private Room room;
> > >
> > > }
> > >
> > > public class Room {
> > >
> > > /**
> > >* --- PK ---
> > >* @ojb.field primarykey="true"
> > >* autoincrement="ojb"
> > >*/
> > > private Integer pk=null;
> > >
> > > /**
> > > * Students in this room
> > > * @ojb.collection
> > > *foreignkey="fk"
> > > *element-class-ref="kdms.core.persistent.User"
> > > *auto-update="true"
> > > *auto-retrieve="true"
> > > *auto-delete="false"
> > > */
> > > private Vector users;
> > > }
> > >
> > > -
> > > 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: Strange behaviour for PersistenceBroker.getCount() on ReportQueryByCriteria
hi danilo,
my comment is correct ms-sql platform uses "+" as concatenation
character. is this wrong ?
jakob
Jakob Braeuchi schrieb:
hi danilo,
Danilo Tommasina schrieb:
An addition to my previous post:
I saw in the BrokerHelper class that the Platform.concatenate() method
is used to combine multi-primary keys, however there is a problem:
The method is thought for concatenating strings and not numeric
fields. For ex. in Sybase and MS-SQL you use the || character for
string concatenation, but the count( distinct expr ) ) clause uses the
+ character, other dbms use also other syntax. I think that a separate
afaik the platform for ms-sql also uses || for concatenation. i think my
comment in BrokerHelper is wrong.
jakob
method should be added for this purpose, something like
concatForDistinct() that would generate the correct String for the
distinct clause.
Hi,
(Using OJB 1.0.1)
I think the PersistenceBroker.getCount() on ReportQueryByCriteria
used on joined tables produces wrong or at least unexpected results. :)
An example:
( Table 1 ) 1 -> N ( Table 2 )
Build a ReportQueryByCriteria like this: new ReportQueryByCriteria(
Table1.class, new String [] { "table1PK", "pathToTable2.table2PK" },
criteria );
now calling PersistenceBroker.getCount( reportQuery ) will produce a
count( * ) statement, which can deliver different results than count(
table1PK, table2PK ) depending on the used join clause and the WHERE
criterias.
Furthermore if setting the query to DISTINCT, OJB uses the PK
column(s) of the 'searchClass' and generates following statement:
SELECT count( distinct table1PK ) ... which will also not produce the
expected result, at least the one expected by me :)
I think the correct query (distinct and not) should just contain the
same columns defined in the original ReportQuery.
OJB shares the same core algorithm for generating the count query for
QueryByCriteria and ReportQueryByCriteria, while for the
QueryByCriteria the algorithm is correct for the ReportQuery it
probably isn't.
The 'evil' code is in class org.apache.ojb.broker.util.BrokerHelper
bye
danilo
-
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: Strange behaviour for PersistenceBroker.getCount() on ReportQueryByCriteria
hi danilo,
Danilo Tommasina schrieb:
An addition to my previous post:
I saw in the BrokerHelper class that the Platform.concatenate() method
is used to combine multi-primary keys, however there is a problem:
The method is thought for concatenating strings and not numeric fields.
For ex. in Sybase and MS-SQL you use the || character for string
concatenation, but the count( distinct expr ) ) clause uses the +
character, other dbms use also other syntax. I think that a separate
afaik the platform for ms-sql also uses || for concatenation. i think my
comment in BrokerHelper is wrong.
jakob
method should be added for this purpose, something like
concatForDistinct() that would generate the correct String for the
distinct clause.
Hi,
(Using OJB 1.0.1)
I think the PersistenceBroker.getCount() on ReportQueryByCriteria used
on joined tables produces wrong or at least unexpected results. :)
An example:
( Table 1 ) 1 -> N ( Table 2 )
Build a ReportQueryByCriteria like this: new ReportQueryByCriteria(
Table1.class, new String [] { "table1PK", "pathToTable2.table2PK" },
criteria );
now calling PersistenceBroker.getCount( reportQuery ) will produce a
count( * ) statement, which can deliver different results than count(
table1PK, table2PK ) depending on the used join clause and the WHERE
criterias.
Furthermore if setting the query to DISTINCT, OJB uses the PK
column(s) of the 'searchClass' and generates following statement:
SELECT count( distinct table1PK ) ... which will also not produce the
expected result, at least the one expected by me :)
I think the correct query (distinct and not) should just contain the
same columns defined in the original ReportQuery.
OJB shares the same core algorithm for generating the count query for
QueryByCriteria and ReportQueryByCriteria, while for the
QueryByCriteria the algorithm is correct for the ReportQuery it
probably isn't.
The 'evil' code is in class org.apache.ojb.broker.util.BrokerHelper
bye
danilo
-
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: Strange behaviour for PersistenceBroker.getCount() on ReportQueryByCriteria
hi danilo,
i appreciate any help on this topic. could you please post the sql that
you think should be generated ?
i'll have a look at it asap.
jakob
Danilo Tommasina schrieb:
I am doing a monologue :(
for the count distinct variant a possible 'database independant'
solution could be to change the code in BrokerHelper and 'simulate' a
distinct clause with a groupBy on all requested columns instead of
generating the database dependant SQL portion.
for the non-distinct count: instead of generating a count(*) you should
generate a count( attr1, attr2, ... ) where attr1, attr2,... are the
columns defined in the ReportQuery
I do not know how using a groupBy instead of a distinct can affect
performance, maybe some database guru may post some more info :)
Maybe somebody would like to know why I am so interested in this stuff...
The problem is:
We have a dinamically generated query that may potentially deliver lots
of results > 5, the results must be shown on a web page. If we
wouldn't limit the max. number of results and display everything on the
web page, this would just kill the app. server.
So what we do is:
- Generate the query
- Execute a count on the query and if it exceeds the max. number of
results throw an exception
- If the no. of results is ok, execute the *same* query (no count this
time) and materialise the results
This works like a charm for QueryByCriteria, but doesn't with the
ReportQueryByCriteria since the 'count' delivers a different number than
the size of the results collection delivered by executing the complete
query.
hopefully the last post...
bye
danilo
An addition to my previous post:
I saw in the BrokerHelper class that the Platform.concatenate() method
is used to combine multi-primary keys, however there is a problem:
The method is thought for concatenating strings and not numeric
fields. For ex. in Sybase and MS-SQL you use the || character for
string concatenation, but the count( distinct expr ) ) clause uses the
+ character, other dbms use also other syntax. I think that a separate
method should be added for this purpose, something like
concatForDistinct() that would generate the correct String for the
distinct clause.
Hi,
(Using OJB 1.0.1)
I think the PersistenceBroker.getCount() on ReportQueryByCriteria
used on joined tables produces wrong or at least unexpected results. :)
An example:
( Table 1 ) 1 -> N ( Table 2 )
Build a ReportQueryByCriteria like this: new ReportQueryByCriteria(
Table1.class, new String [] { "table1PK", "pathToTable2.table2PK" },
criteria );
now calling PersistenceBroker.getCount( reportQuery ) will produce a
count( * ) statement, which can deliver different results than count(
table1PK, table2PK ) depending on the used join clause and the WHERE
criterias.
Furthermore if setting the query to DISTINCT, OJB uses the PK
column(s) of the 'searchClass' and generates following statement:
SELECT count( distinct table1PK ) ... which will also not produce the
expected result, at least the one expected by me :)
I think the correct query (distinct and not) should just contain the
same columns defined in the original ReportQuery.
OJB shares the same core algorithm for generating the count query for
QueryByCriteria and ReportQueryByCriteria, while for the
QueryByCriteria the algorithm is correct for the ReportQuery it
probably isn't.
The 'evil' code is in class org.apache.ojb.broker.util.BrokerHelper
bye
danilo
-
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: Non-Decomposed m:n Mappings
think there is something wrong with the
Profile:
...
collection-class="org.apache.ojb.broker.util.collections.ManageableVector"
auto-retrieve="true"
auto-update="true"
auto-delete="link"
indirection-table="dps_user_org">
I suppose the above settings are correct, then ==>
Organization:
==> shouldn't it be Profile?
collection-class="org.apache.ojb.broker.util.collections.ManageableVector"
auto-retrieve="true"
auto-update="false"
auto-delete="false"
### ==> try same settings as above first
indirection-table="dps_user_org">
### ==> should be vice versa
regards,
Armin
p b wrote:
Thanks for the answer Armin
Here is the core of the StoreUseCase:
public void apply() throws UseCaseException {
logger.info("apply");
PersistenceBroker broker = null;
try {
broker = PersistenceBrokerFactory.defaultPersistenceBroker();
broker.beginTransaction();
broker.store(profile);
broker.commitTransaction();
} catch (PersistenceBrokerException e) {
if (broker != null)
broker.abortTransaction();
e.printStackTrace();
throw new UseCaseException();
} finally {
if (broker != null)
broker.close();
}
}
Here the class descriptor:
collection-class="org.apache.ojb.broker.util.collections.ManageableVector"
auto-retrieve="true"
auto-update="true"
auto-delete="link"
indirection-table="dps_user_org">
auto-retrieve="true"
auto-update="false"
auto-delete="false">
collection-class="org.apache.ojb.broker.util.collections.ManageableVector"
auto-retrieve="true"
auto-update="false"
auto-delete="false"
indirection-table="dps_user_org">
This works perfectly with OJB 1.0.0
Thanks
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Non-Decomposed m:n Mappings
Thanks for the answer Armin
Here is the core of the StoreUseCase:
public void apply() throws UseCaseException {
logger.info("apply");
PersistenceBroker broker = null;
try {
broker =
PersistenceBrokerFactory.defaultPersistenceBroker();
broker.beginTransaction();
broker.store(profile);
broker.commitTransaction();
} catch (PersistenceBrokerException e) {
if (broker != null)
broker.abortTransaction();
e.printStackTrace();
throw new UseCaseException();
} finally {
if (broker != null)
broker.close();
}
}
Here the class descriptor:
collection-class="org.apache.ojb.broker.util.collections.ManageableVector"
auto-retrieve="true"
auto-update="true"
auto-delete="link"
indirection-table="dps_user_org">
auto-retrieve="true"
auto-update="false"
auto-delete="false">
collection-class="org.apache.ojb.broker.util.collections.ManageableVector"
auto-retrieve="true"
auto-update="false"
auto-delete="false"
indirection-table="dps_user_org">
This works perfectly with OJB 1.0.0
Thanks
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
FW: Materialising the wrong type of object when prefetching relat ionships where related class is part of extent
Sorry -- should have gone to ojb-user! BTW -- the class that OJB thinks it should get the class descriptor for is the "first" (look in ChainingIterator for what this means) concrete sub-class in the extent. Many thanks Mark -Original Message- From: Mark Rowell Sent: 25 January 2005 12:25 To: 'ojb-dev@db.apache.org' Subject: Materialising the wrong type of object when prefetching relationships where related class is part of extent Hi I have loked on the ail list and found something similar to this. Certain times when I query a particular class That is not part of an extent but has (indirect) references to other objects that are part of an extent I get materialisation errors: org.apache.ojb.broker.metadata.MetadataException: IllegalAccess error setting field:rank in object:com.credittrade.instruments.derivatives.CreditDefaultSwap at org.apache.ojb.broker.accesslayer.BasePrefetcher.prefetchRelationship(BasePr efetcher.java:137) at org.apache.ojb.broker.core.QueryReferenceBroker.performRetrievalTasks(QueryR eferenceBroker.java:329) at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryRe ferenceBroker.java:167) at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryRe ferenceBroker.java:233) at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryRe ferenceBroker.java:253) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Persis tenceBrokerImpl.java:1217) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery( DelegatingPersistenceBroker.java:338) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery( DelegatingPersistenceBroker.java:338) at com.credittrade.market.pc.options.OptionPriceLoader.fillOutReferenceLevels(O ptionPriceLoader.java:83) at com.credittrade.market.pc.PriceLoaderAbstractImpl.fillOutLastTraded(PriceLoa derAbstractImpl.java:313) at com.credittrade.market.pc.PriceLoaderAbstractImpl.initialLoad(PriceLoaderAbs tractImpl.java:57) at com.credittrade.market.pc.ClientPriceLoader$InitialLoad.execute(ClientPriceL oader.java:99) at com.credittrade.system.js.RPCTaskEntry.execute(RPCTaskEntry.java:63) at com.credittrade.system.js.TaskEntryProcessor.processEntry(TaskEntryProcessor .java:41) at com.credittrade.system.js.SpaceWorker$HandOff.run(SpaceWorker.java:230) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.ja va:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:6 75) at java.lang.Thread.run(Thread.java:595) After delving through the code even though OJB "knows" that I am trying to materialize an instance of a CreditDefaultSwap It is using the class/field descriptors for another type in the extent. The class I want (CreditDefaultSwap) Has a field converter for the field/column causing the problem but the other class does not & hence when OJB attempts to set The field into the object we get an IllegalAccessException as it is triyng to place an unconverted value into the field. All classes in the extent causing the problem are mapped onto a single table. The primary key is an INTEGER and is guarantted to be Unique (I have a UNIQUE PK constraint on the column) and I have queried the table for the relevant ID (for the problem object The primary key has the right ojbConcreteClass value in the table (CreditDefaultSwap). Has anyone come up against this before. I am using v1.0.1 & Java 5. The line numbers may not quite be correct as I have some print statement in place for debugging... Thanks Mark Rowell --- Mark Rowell Structured Credit Europe CreditTrade Limited No. 1 London Bridge, 6th Floor London SE1 9QL Tel +44 (0)20 7098 1653 http://www.credittrade.com CreditTrade Limited is regulated by the FSA. (c) CreditTrade 2005. All rights reserved. The information and data contained in this email is provided for the information purposes of the addressee only and should not be reproduced and/or distributed to any other person. It is provided without any warranty whatsoever and unless stated otherwise consists purely of indicative market prices and other information. Any opinion or comments expressed or assumption made in association with the data or information provided in this email is a reflection of CreditTrades judgement at the time of compiling the data and is subject to change. CreditTrade hereby makes no representation and accepts no responsibility or liability as to the completeness or accuracy of this email. The content of this email is not intended as an offer or solicitation for, or recommendation of, the purchase or sale of any financial instrument, or as an official confirmation of any transaction, and should not be construed as investment advice.
Re: remove table alias in generated SQL?
Antonio - Thanx for the insight. The only reason that I didn't go with ReportQueries is because the application I have needs to be configured w/ the repository.xml file, not by myself, but by the client - someone with absolutely NO experience or knowledge of OJB. Because the database schemas could change between clients and I wanted to use the same application per client, I couldn't use ReportQueries because you can't configure them with the XML descriptors. --Bobby Antonio Gallardo wrote: On Lun, 24 de Enero de 2005, 8:32, Bobby Lawrence dijo: Not having an alias would allow you to use functions and string literals. You could specify a string literal in the field-descriptor like this: This would give you the same value for every class instance, which might not seem that useful at first, but this is exactly what I needed in my project for a brief time. At the time, I was expecting values from the database where the field did not exist yet and I needed something to test. Is posible to test for null? You could also specify functions in the field-descriptor like this: If using an Oracle database, this would concatenate the first and last names to give you a whole name. Could be used in a ReportQuery if we make it resolve more than 1 field in a expresion. Another example on concatenation w/ Oracle without using the function: Works in PostgreSQL too, again the solution is using a ReportQuery that solves multiplefields in one expresion. All of these should be possible if OJB didn't use table aliases in its generated SQL statements. While the theory indicates that each field in the database must have a unique name. In the practice, we found that in some databases, the users choose same names for fields in diferentables. Sample: table1.ID table2.ID the same field name "ID" should be resolved and this is why I think OJB choosed to use SQL table alias to resolve this names. What IS the benefit of using an alias? Not being a big fan of SQL alias, but what I understand: 1-This is convenient when you want to obtain information from two separate tables (the technical term is 'perform joins'). The advantage of using a table alias when doing joins is readily apparent when we talk about joins. 2- Generate shorter queries: SELECT from mylongnametable.fieldA, mylongnametable.fieldB FROM mylongnametable; vs. SELECT from A0.fieldA, A0.fieldB FROM mylongnametable A0; Hope this helps, Best Regards, Antonio Gallardo. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Bobby Lawrence MIS Application Developer Jefferson Lab (www.jlab.org) Email: [EMAIL PROTECTED] Office: (757) 269-5818 Pager: (757) 584-5818
Re: Crossreferenced Objects
I think the problems comes from the cache implementation I use,
because It used to work quite well with jUnit tests and Default Cache
Implementation, and in this situation there is only One thread so
there wasn't any "dirty read" problem.
However, since I moved the application in Struts Actions Under tomcat,
I couldn't use the default Cache Implementation since it is not
thread-safe, and I got some errors with retrieved data. So, I thought
that using a thread-safe cache implementation such as
"ObjectCachePerBrokerImpl" could solve the problem, and by doing so I
solved the problems that used to happen, until I tried Crossreferenced
Objects...
I think that the source of the problem can be that I don't have any
global cache, because I retrieve first the Room Object and the nested
collection in a Struts Action (that might be running it it's own
thread), and then on the users collection elements I try to get
information on rooms, and it runs on a different thread from the first
Action since it located in a different Action.
So, I think that using a global cache which is thread-safe could solve
this issue, however there is only few documentation on caches
implementations in the cache package.
As I read in the javadoc, it seems that ObjectCachePerClassImpl is a
global cache, but i don't know if it thread-safe at all.
I retrieve Objects using this code :
public StorableObject get(Class objectClass, Integer pk) {
PersistenceBroker broker = null;
Object result;
Criteria crit = new Criteria();
crit.addEqualTo("pk",pk);
crit = criteraModificator(objectClass, crit);
try {
broker = PersistenceBrokerFactory.defaultPersistenceBroker();
QueryByCriteria query = new QueryByCriteria(objectClass, crit);
result = broker.getObjectByQuery(query);
} finally {
if (broker != null)
broker.close();
}
return (StorableObject)result;
}
Regards,
Sylvain.
On Tue, 25 Jan 2005 11:23:02 +0100, Armin Waibel <[EMAIL PROTECTED]> wrote:
> Hi,
>
> which version of OJB do you use?
> Did you try the default ObjectCache implementation? Same result?
> How does your code look like?
>
> regards,
> Armin
>
> Sylvain ~ wrote:
> > Hi,
> >
> > I'm trying to create crossreferenced objects, as specified in the
> > Cache documentation :
> >
> > "It allows to perform circular lookups (as by crossreferenced
> > objects) that would result in non-terminating loops without such a
> > cache."
> >
> > I Use ObjectCachePerBrokerImpl since my application is multi-threaded
> > (and runs on tomcat)
> >
> > The problem is that I get a java.lang.StackOverflowError, when trying
> > to do so with theses classes (simplified for clarity). both classes
> > have auto-retrieve="true".
> >
> > Any Idea to make it work would be appreciated.
> > Sylvain.
> >
> > public class User {
> >
> >/**
> >* --- PK ---
> >* @ojb.field primarykey="true"
> >* autoincrement="ojb"
> >*/
> > private Integer pk=null;
> >
> > /**
> > * user room
> > * @ojb.reference
> > *foreignkey="pk"
> > */
> > private Room room;
> >
> > }
> >
> > public class Room {
> >
> > /**
> >* --- PK ---
> >* @ojb.field primarykey="true"
> >* autoincrement="ojb"
> >*/
> > private Integer pk=null;
> >
> > /**
> > * Students in this room
> > * @ojb.collection
> > *foreignkey="fk"
> > *element-class-ref="kdms.core.persistent.User"
> > *auto-update="true"
> > *auto-retrieve="true"
> > *auto-delete="false"
> > */
> > private Vector users;
> > }
> >
> > -
> > 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: Strange behaviour for PersistenceBroker.getCount() on ReportQueryByCriteria
I am doing a monologue :(
for the count distinct variant a possible 'database independant' solution could be to change the code in BrokerHelper and 'simulate' a distinct clause with a groupBy on all
requested columns instead of generating the database dependant SQL portion.
for the non-distinct count: instead of generating a count(*) you should
generate a count( attr1, attr2, ... ) where attr1, attr2,... are the columns
defined in the ReportQuery
I do not know how using a groupBy instead of a distinct can affect performance,
maybe some database guru may post some more info :)
Maybe somebody would like to know why I am so interested in this stuff...
The problem is:
We have a dinamically generated query that may potentially deliver lots of results > 5, the results must be shown on a web page. If we wouldn't limit the max. number of results
and display everything on the web page, this would just kill the app. server.
So what we do is:
- Generate the query
- Execute a count on the query and if it exceeds the max. number of results
throw an exception
- If the no. of results is ok, execute the *same* query (no count this time)
and materialise the results
This works like a charm for QueryByCriteria, but doesn't with the ReportQueryByCriteria since the 'count' delivers a different number than the size of the results collection
delivered by executing the complete query.
hopefully the last post...
bye
danilo
An addition to my previous post:
I saw in the BrokerHelper class that the Platform.concatenate() method
is used to combine multi-primary keys, however there is a problem:
The method is thought for concatenating strings and not numeric fields.
For ex. in Sybase and MS-SQL you use the || character for string
concatenation, but the count( distinct expr ) ) clause uses the +
character, other dbms use also other syntax. I think that a separate
method should be added for this purpose, something like
concatForDistinct() that would generate the correct String for the
distinct clause.
Hi,
(Using OJB 1.0.1)
I think the PersistenceBroker.getCount() on ReportQueryByCriteria used
on joined tables produces wrong or at least unexpected results. :)
An example:
( Table 1 ) 1 -> N ( Table 2 )
Build a ReportQueryByCriteria like this: new ReportQueryByCriteria(
Table1.class, new String [] { "table1PK", "pathToTable2.table2PK" },
criteria );
now calling PersistenceBroker.getCount( reportQuery ) will produce a
count( * ) statement, which can deliver different results than count(
table1PK, table2PK ) depending on the used join clause and the WHERE
criterias.
Furthermore if setting the query to DISTINCT, OJB uses the PK
column(s) of the 'searchClass' and generates following statement:
SELECT count( distinct table1PK ) ... which will also not produce the
expected result, at least the one expected by me :)
I think the correct query (distinct and not) should just contain the
same columns defined in the original ReportQuery.
OJB shares the same core algorithm for generating the count query for
QueryByCriteria and ReportQueryByCriteria, while for the
QueryByCriteria the algorithm is correct for the ReportQuery it
probably isn't.
The 'evil' code is in class org.apache.ojb.broker.util.BrokerHelper
bye
danilo
-
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: remove table alias in generated SQL?
I'm not so sure about that. Being able to define expressions that are used during SELECT/INSERT/UPDATE would provide some value and remove the need for some field conversions which might be beneficial to performance as well (as the database performs the conversion, not the app). Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Strange behaviour for PersistenceBroker.getCount() on ReportQueryByCriteria
An addition to my previous post:
I saw in the BrokerHelper class that the Platform.concatenate() method is used to combine multi-primary keys, however there is a problem:
The method is thought for concatenating strings and not numeric fields. For ex. in Sybase and MS-SQL you use the || character for string concatenation, but the count( distinct expr
) ) clause uses the + character, other dbms use also other syntax. I think that a separate method should be added for this purpose, something like concatForDistinct() that would
generate the correct String for the distinct clause.
Hi,
(Using OJB 1.0.1)
I think the PersistenceBroker.getCount() on ReportQueryByCriteria used
on joined tables produces wrong or at least unexpected results. :)
An example:
( Table 1 ) 1 -> N ( Table 2 )
Build a ReportQueryByCriteria like this: new ReportQueryByCriteria(
Table1.class, new String [] { "table1PK", "pathToTable2.table2PK" },
criteria );
now calling PersistenceBroker.getCount( reportQuery ) will produce a
count( * ) statement, which can deliver different results than count(
table1PK, table2PK ) depending on the used join clause and the WHERE
criterias.
Furthermore if setting the query to DISTINCT, OJB uses the PK column(s)
of the 'searchClass' and generates following statement: SELECT count(
distinct table1PK ) ... which will also not produce the expected result,
at least the one expected by me :)
I think the correct query (distinct and not) should just contain the
same columns defined in the original ReportQuery.
OJB shares the same core algorithm for generating the count query for
QueryByCriteria and ReportQueryByCriteria, while for the QueryByCriteria
the algorithm is correct for the ReportQuery it probably isn't.
The 'evil' code is in class org.apache.ojb.broker.util.BrokerHelper
bye
danilo
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Danilo Tommasina, Dipl. Ing. FH Telecom
Software Engineer
RCS Riskmanagement Concepts Systems AG
Technoparkstrasse 1
CH-8005 Zuerich
T: +41 1 445 29 08
[EMAIL PROTECTED]
www.risksys.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Crossreferenced Objects
Hi,
which version of OJB do you use?
Did you try the default ObjectCache implementation? Same result?
How does your code look like?
regards,
Armin
Sylvain ~ wrote:
Hi,
I'm trying to create crossreferenced objects, as specified in the
Cache documentation :
"It allows to perform circular lookups (as by crossreferenced
objects) that would result in non-terminating loops without such a
cache."
I Use ObjectCachePerBrokerImpl since my application is multi-threaded
(and runs on tomcat)
The problem is that I get a java.lang.StackOverflowError, when trying
to do so with theses classes (simplified for clarity). both classes
have auto-retrieve="true".
Any Idea to make it work would be appreciated.
Sylvain.
public class User {
/**
* --- PK ---
* @ojb.field primarykey="true"
* autoincrement="ojb"
*/
private Integer pk=null;
/**
* user room
* @ojb.reference
* foreignkey="pk"
*/
private Room room;
}
public class Room {
/**
* --- PK ---
* @ojb.field primarykey="true"
* autoincrement="ojb"
*/
private Integer pk=null;
/**
* Students in this room
* @ojb.collection
* foreignkey="fk"
* element-class-ref="kdms.core.persistent.User"
* auto-update="true"
* auto-retrieve="true"
* auto-delete="false"
*/
private Vector users;
}
-
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: Non-Decomposed m:n Mappings
Hi,
only problems I know is when using ODMG-api with non-dec.-m:n (see
release-notes). Could you post the metadata declaration of the m:n
relation and the (pseudo) code of StoreUseCase.
regards,
Armin
p b wrote:
Hello,
we are migrating from OJB 1.0 to 1.0.1
I have a Non-Decomposed m:n Mappings working perfectly under 1.0, after
the migration to 1.0.1 (added the
collection-class="org.apache.ojb.broker.util.collections.ManageableVector"
in table descriptors) I have a
org.apache.ojb.broker.KeyConstraintViolatedException: SQL failure while
insert object data for class it.gesi.userprofiling.Profile, PK of the
given object is [ id=39426443], object was Profile
The test is stupid enough:
...
{
StoreUseCase useCase1 = new StoreUseCase();
useCase1.setProfile(profile);
useCase1.apply();
StoreUseCase useCase2 = new StoreUseCase();
useCase2.setProfile(profile);
useCase2.apply();
}
Anyone have seen this before
Thanks
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Strange behaviour for PersistenceBroker.getCount() on ReportQueryByCriteria
Hi,
(Using OJB 1.0.1)
I think the PersistenceBroker.getCount() on ReportQueryByCriteria used on
joined tables produces wrong or at least unexpected results. :)
An example:
( Table 1 ) 1 -> N ( Table 2 )
Build a ReportQueryByCriteria like this: new ReportQueryByCriteria( Table1.class, new String [] {
"table1PK", "pathToTable2.table2PK" }, criteria );
now calling PersistenceBroker.getCount( reportQuery ) will produce a count( * ) statement, which can deliver different results than count( table1PK, table2PK ) depending on the
used join clause and the WHERE criterias.
Furthermore if setting the query to DISTINCT, OJB uses the PK column(s) of the 'searchClass' and generates following statement: SELECT count( distinct table1PK ) ... which will
also not produce the expected result, at least the one expected by me :)
I think the correct query (distinct and not) should just contain the same columns defined in the original ReportQuery.
OJB shares the same core algorithm for generating the count query for QueryByCriteria and ReportQueryByCriteria, while for the QueryByCriteria the algorithm is correct for the
ReportQuery it probably isn't.
The 'evil' code is in class org.apache.ojb.broker.util.BrokerHelper
bye
danilo
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Crossreferenced Objects
Hi,
I'm trying to create crossreferenced objects, as specified in the
Cache documentation :
"It allows to perform circular lookups (as by crossreferenced
objects) that would result in non-terminating loops without such a
cache."
I Use ObjectCachePerBrokerImpl since my application is multi-threaded
(and runs on tomcat)
The problem is that I get a java.lang.StackOverflowError, when trying
to do so with theses classes (simplified for clarity). both classes
have auto-retrieve="true".
Any Idea to make it work would be appreciated.
Sylvain.
public class User {
/**
* --- PK ---
* @ojb.field primarykey="true"
* autoincrement="ojb"
*/
private Integer pk=null;
/**
* user room
* @ojb.reference
* foreignkey="pk"
*/
private Room room;
}
public class Room {
/**
* --- PK ---
* @ojb.field primarykey="true"
* autoincrement="ojb"
*/
private Integer pk=null;
/**
* Students in this room
* @ojb.collection
* foreignkey="fk"
* element-class-ref="kdms.core.persistent.User"
* auto-update="true"
* auto-retrieve="true"
* auto-delete="false"
*/
private Vector users;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
