additional info
when using an odmg-query instead of a pb-Query (in the code that fails to execute), I get the following error: What is the reason for this? I have the db openend read-write, Transaction is is also open, Any clue? -Gunnar [org.apache.ojb.odmg.TransactionImpl] ERROR: Locking obj [EMAIL PROTECTED] with lock mode 1 failed null java.lang.ClassCastException at org.apache.ojb.broker.core.QueryReferenceBroker$PBCollectionProxyListener.addThisListenerTo(Unknown Source) at org.apache.ojb.broker.core.QueryReferenceBroker$PBPrefetchingListener.prefetch(Unknown Source) at org.apache.ojb.broker.core.QueryReferenceBroker$PBCollectionProxyListener.beforeLoading(Unknown Source) at org.apache.ojb.broker.accesslayer.CollectionProxy.beforeLoading(Unknown Source) at org.apache.ojb.broker.accesslayer.CollectionProxy.loadData(Unknown Source) at org.apache.ojb.broker.accesslayer.ListProxy.loadData(Unknown Source) at org.apache.ojb.broker.accesslayer.CollectionProxy.getData(Unknown Source) at org.apache.ojb.broker.accesslayer.CollectionProxy.iterator(Unknown Source) at org.apache.ojb.broker.accesslayer.CollectionProxy.ojbIterator(Unknown Source) at org.apache.ojb.odmg.TransactionImpl.lockCollections(Unknown Source) at org.apache.ojb.odmg.TransactionImpl.register(Unknown Source) at org.apache.ojb.odmg.TransactionImpl.lock(Unknown Source) at org.apache.ojb.odmg.oql.OQLQueryImpl.performLockingIfRequired(Unknown Source) at org.apache.ojb.odmg.oql.OQLQueryImpl.execute(Unknown Source) at de.infomantis.lotto.ejb.Util.erzeugeTippScheine(Util.java:109) at de.infomantis.lotto.ejb.Util.main(Util.java:175) rethrown as org.apache.ojb.broker.PersistenceBrokerException at org.apache.ojb.broker.accesslayer.CollectionProxy.loadData(Unknown Source) at org.apache.ojb.broker.accesslayer.ListProxy.loadData(Unknown Source) at org.apache.ojb.broker.accesslayer.CollectionProxy.getData(Unknown Source) at org.apache.ojb.broker.accesslayer.CollectionProxy.iterator(Unknown Source) at org.apache.ojb.broker.accesslayer.CollectionProxy.ojbIterator(Unknown Source) at org.apache.ojb.odmg.TransactionImpl.lockCollections(Unknown Source) at org.apache.ojb.odmg.TransactionImpl.register(Unknown Source) at org.apache.ojb.odmg.TransactionImpl.lock(Unknown Source) at org.apache.ojb.odmg.oql.OQLQueryImpl.performLockingIfRequired(Unknown Source) at org.apache.ojb.odmg.oql.OQLQueryImpl.execute(Unknown Source) at de.infomantis.lotto.ejb.Util.erzeugeTippScheine(Util.java:109) at de.infomantis.lotto.ejb.Util.main(Util.java:175) Caused by: java.lang.ClassCastException at org.apache.ojb.broker.core.QueryReferenceBroker$PBCollectionProxyListener.addThisListenerTo(Unknown Source) at org.apache.ojb.broker.core.QueryReferenceBroker$PBPrefetchingListener.prefetch(Unknown Source) at org.apache.ojb.broker.core.QueryReferenceBroker$PBCollectionProxyListener.beforeLoading(Unknown Source) at org.apache.ojb.broker.accesslayer.CollectionProxy.beforeLoading(Unknown Source) ... 12 more java.lang.IllegalArgumentException at de.infomantis.lotto.ejb.Util.erzeugeTippScheine(Util.java:111) at de.infomantis.lotto.ejb.Util.main(Util.java:175) failed - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
identical code fails one place, works in an other
Hello, I got a serious problem with a strange class cast exception: Collection ress=tipp.getReservierungen(); Iterator j=ress.iterator(); causes a ClassCassException in the second line, but only in one program, an other one works with the same repository (snippet): Complete stack follows. Help! Who has any clue how this can happen? Thanks in advance, -Gunnar STACKTRACE: found 62 tipps java.lang.ClassCastException at org.apache.ojb.broker.core.QueryReferenceBroker$PBCollectionProxyListener.addThisListenerTo(Unknown Source) at org.apache.ojb.broker.core.QueryReferenceBroker$PBPrefetchingListener.prefetch(Unknown Source) at org.apache.ojb.broker.core.QueryReferenceBroker$PBCollectionProxyListener.beforeLoading(Unknown Source) at org.apache.ojb.broker.accesslayer.CollectionProxy.beforeLoading(Unknown Source) at org.apache.ojb.broker.accesslayer.CollectionProxy.loadData(Unknown Source) at org.apache.ojb.broker.accesslayer.ListProxy.loadData(Unknown Source) at org.apache.ojb.broker.accesslayer.CollectionProxy.getData(Unknown Source) at org.apache.ojb.broker.accesslayer.CollectionProxy.iterator(Unknown Source) at de.infomantis.lotto.ejb.Util.erzeugeTippScheine(Util.java:112) at de.infomantis.lotto.ejb.Util.main(Util.java:162) rethrown as org.apache.ojb.broker.PersistenceBrokerException at org.apache.ojb.broker.accesslayer.CollectionProxy.loadData(Unknown Source) at org.apache.ojb.broker.accesslayer.ListProxy.loadData(Unknown Source) at org.apache.ojb.broker.accesslayer.CollectionProxy.getData(Unknown Source) at org.apache.ojb.broker.accesslayer.CollectionProxy.iterator(Unknown Source) at de.infomantis.lotto.ejb.Util.erzeugeTippScheine(Util.java:112) at de.infomantis.lotto.ejb.Util.main(Util.java:162) Caused by: java.lang.ClassCastException at org.apache.ojb.broker.core.QueryReferenceBroker$PBCollectionProxyListener.addThisListenerTo(Unknown Source) at org.apache.ojb.broker.core.QueryReferenceBroker$PBPrefetchingListener.prefetch(Unknown Source) at org.apache.ojb.broker.core.QueryReferenceBroker$PBCollectionProxyListener.beforeLoading(Unknown Source) at org.apache.ojb.broker.accesslayer.CollectionProxy.beforeLoading(Unknown Source) ... 6 more failed - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Sequence Manager for HSQLDB + JBOSS
Fellow OJBers,
I have an application running on JBoss 3.0.8, using
the latest version of OJB (from CVS). I'm using the
provided HSQLDB version that comes with JBoss.
I have a couple of questions on the setup:
1). Which OJB internal tables do I need? When are this
tables generated. I see them in them in
repository_internal.xml. Do they get created the first
time they are needed? Or do I have to create them?
2). From reading the newsgroups posting I see that hsql
does not support database based key generation. So I
switch the sequence manager className in my jdbc
connection to use the HighLo Seq manager. Of course
that one depends on one of the internal tables. I'm
assuming that if the database is not shared the
InMemory manager is the way to go for performance
reasons, right?
3.) THe application in its current state uses a
SessionBean to do all of the data access. I seem to be
able to do queries just fine but when I try to insert a
new object I get the error shown below. Also, the PK
for this object is an Integer field. Should I set that
value to null for a new object, since the Seq. Manager
is going to assign that value? I don't see the Seq Man
classes involved in the error below. So I guess it
might be something I goofed on. Any help would be
appreaciated. I have followed the instructions on the
deployment page, for deploying on JBoss (sar creation).
Here's one of the simple mappings that produces the
error below
The code for this looks like (in the SessionBean)
...
* @ejb.bean
* name="ConferenceFacade"
* type="Stateless"
* view-type="both"
* jndi-name="ejb.ConferenceFacadeHome"
* local-jndi-name="ejb.ConferenceFacadeLocalHome"
* @ejb.transaction
* type="Required"
* @ejb.util
* generate="physical"
*/
public abstract class ConferenceFacadeBean implements
SessionBean {
...
/**
* @ejb.interface-method
* @ejb.transaction
* type="NotSupported"
*
* @return
*/
public boolean saveConference(Conference conference) {
PersistenceBroker broker =
pbf.defaultPersistenceBroker();
boolean result = true;
try {
broker.beginTransaction();
broker.store(conference);
broker.commitTransaction();
} catch (PersistenceBrokerException pbe) {
result = false;
broker.abortTransaction();
} finally {
if (broker != null) broker.close();
}
return result;
}
...
2004-01-03 21:58:33,534 ERROR
[org.apache.ojb.broker.accesslayer.JdbcAccessImpl]
SQLException during the execution of the insert (for a
com.ejdoab.pojos.Conference): This function is not
supported
java.sql.SQLException: This function is not supported
at org.hsqldb.Trace.getError(Trace.java:180)
at org.hsqldb.Trace.getError(Trace.java:144)
at org.hsqldb.Trace.error(Trace.java:192)
at
org.hsqldb.jdbcPreparedStatement.getNotSupported(jdbcPreparedStatement.java:1602)
at
org.hsqldb.jdbcPreparedStatement.setCharacterStream(jdbcPreparedStatement.java:1375)
at
org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.setCharacterStream(WrappedPreparedStatement.java:644)
at
org.apache.ojb.broker.platforms.PlatformDefaultImpl.setObjectForStatement(Unknown
Source)
at
org.apache.ojb.broker.accesslayer.StatementManager.bindInsert(Unknown
Source)
at
org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeInsert(Unknown
Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.storeToDb(Unknown Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.store(Unknown Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.store(Unknown Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.store(Unknown Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.store(Unknown Source)
Any guidance would be appreciated.
Regards,
Brian
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: timeout attribute in ObjectCacheDefaultImpl
Hi Armin, Thank you very much for your reply. I forgot to ask you one thing: can I set the ObjectCacheDefaultImpl timeout to infinite (object cache never timeouts)? For example, timeout = -1? Thanks, Jair Jr > Hi, > > Jair da Silva Ferreira Júnior wrote: > > > Hi, > > I am using ojb1.0_rc5, ODMG api with OJB queries, mysql4 (innodb tables) > > in Linux Red Hat 7.3 (kernel 2.4.20-20.7). > > I am using ObjectCacheDefaultImpl in my application as it's > > read-intensive. > > I have some questions about the behavior of the timeout attribute in > > ObjectCacheDefaultImpl. > > 1- Is the timeout attribute new in rc5? In other words, did the > > timeout attribute exist in rc4? > > it's new to rc5 > > > 2- If I configure the cache using the OJB.properties file like this: > > > > ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheDefaultImpl > > descriptorBasedCaches=false > > Is the timeout attribute set to 900 (default)? > > yes, default timeout is 900 sec > > > Is there a way I can set this attribute in the OJB.properties > > file > > no (think in 1.1 Version we will remove cache configuration from > OJB.properties file) > > or is it only set through the tag in the repository? > > yep, within jdbc-connection-descriptor or class-descriptor > > > 3- Is the time counter of a cached object reset when it is updated > > (the object's data is changed and commited to the database)? > > yes > > > 4- If a cached object timeouts and it is still being referenced by > > other objects in my application (it is not elegible for garbage collection), > > will it be returned from cache or will the object's data be reloaded from db > > in the same JVM object or will a new JVM object be created to hold the > > reloaded data? > > timeout has highest priority, thus it will be removed from cache whether > or not it's being referenced by other objects and be reloaded from DB > > regards, > Armin > > > > > Thanks, > > Jair Jr > > > > > > > > - > > 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: cache implementation change in rc5?
Hi Armin,
> Hi Jair jr,
>
> Jair da Silva Ferreira Júnior wrote:
> > Hi Armin,
> > Thank you very much for your fast reply.
> >
> >
> >>it's a(/my) bug in ObjectCacheDefaultImpl (rc5) causing this strange
> >>behaviour. I will check in a fixed version tomorrow.
> >
> >
> > Ok. How can I get the fixed ObjectCacheDefaultImpl implementation?
Only
> > through CVS?
>
> Yes, it's in CVS head. Release date of final 1.0 is 04 Jan (+-?days) and
> it will contain all fixes.
>
> > Are you going to deploy a new rc5 binary version with this fix?
> >
> If you interested in a binary CVS snapshoot I can send you one.
Thanks, but as my project is on schedule I think I can wait for the
final 1.0 OJB version which, as you said, will be available in 1 or 2 days.
Thanks for your help,
Jair Jr
>
> regards,
> Armin
>
>
> > Thanks,
> > Jair Jr
> >
> >
> >>Jair da Silva Ferreira Júnior wrote:
> >>
> >>>Hi,
> >>>I am using ojb1.0_rc5, ODMG api with OJB queries, mysql4 (innodb
> >
> > tables) in Linux Red Hat 7.3 (kernel 2.4.20-20.7).
> >
> >>>I moved from rc4 to rc5 recently and I noticed that sometimes when
I
> >
> > run a query the resulting associated objects don't come from the cache.
> > Please, take a look at the above code to better undestand what I am
saying:
> >
> >>> Transaction t=implementation.newTransaction();
> >>> t.begin();
> >>> Person p=new Person();
> >>> t.lock(p,t.WRITE);
> >>> p.setName("somebody");
> >>> Dog d=new Dog();
> >>> t.lock(d,t.WRITE);
> >>> d.setName("Spike");
> >>> p.setDog(d);
> >>> t.commit();
> >>>
> >>> t=implementation.newTransaction();
> >>> t.begin();
> >>> Criteria crit=new Criteria();
> >>> crit.addEqualTo("_id",new Integer(p.getId()));
> >>> QueryByCriteria query=QueryFactory.newQuery(Person.class,crit);
> >>> PersistenceBroker broker=((HasBroker)t).getBroker();
> >>> broker.removeFromCache(p);
> >>> Person loaded=(Person)broker.getObjectByQuery(query);
> >>> boolean cacheOk=(loaded.getDog()==d); //here cacheOk==false
sometimes
> >>> t.commit();
> >>>
> >>>The atributes (proxy, refresh, auto-retrieve, auto-update and
> >
> > auto-delete) in the reference-descriptor for the association between
Person
> > and Dog have default values. This way, refresh="false".
> >
> >>>This problem does not happen everytime. So, sometimes
cacheOk==true.
> >>>I wasn't able to reproduce this problem in a test case, but it does
> >
> > happen sometimes.
> >
> >>>I've used rc4 for a long time and I've never had this kind of
> >
> > problem.
> >
> >>>Here's my cache configuration in OJB.properties:
> >>>
> >>>
> >
> > ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheDefaultImpl
> >
> >>>descriptorBasedCaches=false
> >>>
> >>>Thanks,
> >>>Jair Jr
> >>
> >>
> >>
> >>-
> >>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]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Issue: PBLifeCycleListener.afterLookup() and batch load in RC5
Just a note: In RC5 in case of batch load event PBLifeCycleListener.afterLookup () may be called when some references in target object is not yet initialized. Thanks, Andy
Re: timeout attribute in ObjectCacheDefaultImpl
Hi, Jair da Silva Ferreira Júnior wrote: Hi, I am using ojb1.0_rc5, ODMG api with OJB queries, mysql4 (innodb tables) in Linux Red Hat 7.3 (kernel 2.4.20-20.7). I am using ObjectCacheDefaultImpl in my application as it's read-intensive. I have some questions about the behavior of the timeout attribute in ObjectCacheDefaultImpl. 1- Is the timeout attribute new in rc5? In other words, did the timeout attribute exist in rc4? it's new to rc5 2- If I configure the cache using the OJB.properties file like this: ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheDefaultImpl descriptorBasedCaches=false Is the timeout attribute set to 900 (default)? yes, default timeout is 900 sec Is there a way I can set this attribute in the OJB.properties file no (think in 1.1 Version we will remove cache configuration from OJB.properties file) or is it only set through the tag in the repository? yep, within jdbc-connection-descriptor or class-descriptor 3- Is the time counter of a cached object reset when it is updated (the object's data is changed and commited to the database)? yes 4- If a cached object timeouts and it is still being referenced by other objects in my application (it is not elegible for garbage collection), will it be returned from cache or will the object's data be reloaded from db in the same JVM object or will a new JVM object be created to hold the reloaded data? timeout has highest priority, thus it will be removed from cache whether or not it's being referenced by other objects and be reloaded from DB regards, Armin Thanks, Jair Jr - 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]
timeout attribute in ObjectCacheDefaultImpl
Hi, I am using ojb1.0_rc5, ODMG api with OJB queries, mysql4 (innodb tables) in Linux Red Hat 7.3 (kernel 2.4.20-20.7). I am using ObjectCacheDefaultImpl in my application as it's read-intensive. I have some questions about the behavior of the timeout attribute in ObjectCacheDefaultImpl. 1- Is the timeout attribute new in rc5? In other words, did the timeout attribute exist in rc4? 2- If I configure the cache using the OJB.properties file like this: ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheDefaultImpl descriptorBasedCaches=false Is the timeout attribute set to 900 (default)? Is there a way I can set this attribute in the OJB.properties file or is it only set through the tag in the repository? 3- Is the time counter of a cached object reset when it is updated (the object's data is changed and commited to the database)? 4- If a cached object timeouts and it is still being referenced by other objects in my application (it is not elegible for garbage collection), will it be returned from cache or will the object's data be reloaded from db in the same JVM object or will a new JVM object be created to hold the reloaded data? Thanks, Jair Jr - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: objects in cache after transaction abort
Hi,
> Is this fix going to be available in the final 1.0 version coming
out in
> 1 or 2 days?
yes, a fix or workaround
regards,
Armin
Jair da Silva Ferreira Júnior wrote:
Hi Armin,
Hi Jair jr,
Jair da Silva Ferreira Júnior wrote:
Hi Armin,
Thank you for your fast reply.
hmm, this should not happend. Do you use checkpoint() or flush()
in your code?
This only could happens when the object was already in DB. Only the
PersistenceBrokerImpl and RsIterator class push objects to cache.
If you abort the tx, the PB instance is not aware of locked objects.
I use flush() and run an OJB query before aborting the transaction.
I
don't use checkpoint().
If you call flush() all objects hold by ODMG-api are written to DB and
thus they are passed to the cache. If you now abort the tx the invalid
objects still in cache. Think this is a bug.
Thanks for the test case, reproduce the problem. Will check in a fix ASAP.
Is this fix going to be available in the final 1.0 version coming out in
1 or 2 days?
Thanks,
Jair Jr
regards,
Armin
Interesting problem, please let me know if you can reproduce it.
I was able to reproduce the problem in the above test case. I hope
it
helps:
Transaction t=implementation.newTransaction();
t.begin();
PersistenceBroker broker=((HasBroker)t).getBroker();
Student s=new Student();
t.lock(s,t.WRITE);
s.setName("student");
s.setEmail("[EMAIL PROTECTED]");
s.setPassword("abcd");
((TransactionExt)t).flush();
Criteria crit=new Criteria();
crit.addEqualTo("_name",s.getName());
QueryByCriteria query=QueryFactory.newQuery(Student.class,crit);
Iterator it=broker.getIteratorByQuery(query);
assertSame(s,it.next());
assertFalse(it.hasNext());
t.abort();
t=implementation.newTransaction();
t.begin();
broker=((HasBroker)t).getBroker();
QueryByIdentity query2=new QueryByIdentity(s);
boolean cacheOk=(broker.getObjectByQuery(query2)==null);
System.out.println("cacheOk: "+cacheOk); //cacheOk==false always
t.commit();
Thanks,
Jair Jr
Jair da Silva Ferreira Júnior wrote:
Hi,
I am using ojb1.0_rc5, ODMG api with OJB queries, mysql4 (innodb
tables) in Linux Red Hat 7.3 (kernel 2.4.20-20.7).
I moved from rc4 to rc5 recently and I noticed that sometimes the
objects persisted inside an aborted transaction are still in cache when
another transaction is started. Please, take a look at the above code to
better undestand what I am saying:
Transaction t=implementation.newTransaction();
t.begin();
Person e=new Person();
t.lock(e,t.WRITE);
e.setName("some exam");
t.abort();
t=implementation.newTransaction();
t.begin();
PersistenceBroker broker=((HasBroker)t).getBroker();
QueryByIdentity query=new QueryByIdentity(e);
Person loaded=(Person)broker.getObjectByQuery(query);
boolean cacheOk=(loaded==null); //here cacheOk==false sometimes
t.commit();
This problem does not happen everytime. So, sometimes
cacheOk==true.
I wasn't able to reproduce this problem in a test case, but it does
happen sometimes.
This problem has never happened when I used rc4.
Here's my cache configuration in OJB.properties:
ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheDefaultImpl
descriptorBasedCaches=false
Thanks,
Jair Jr
-
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]
-
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: objects in cache after transaction abort
Hi Armin,
> Hi Jair jr,
>
> Jair da Silva Ferreira Júnior wrote:
> > Hi Armin,
> >
> > Thank you for your fast reply.
> >
> >
> >>hmm, this should not happend. Do you use checkpoint() or flush()
> >>in your code?
> >>This only could happens when the object was already in DB. Only the
> >>PersistenceBrokerImpl and RsIterator class push objects to cache.
> >>If you abort the tx, the PB instance is not aware of locked objects.
> >
> >
> > I use flush() and run an OJB query before aborting the transaction.
I
> > don't use checkpoint().
> >
>
> If you call flush() all objects hold by ODMG-api are written to DB and
> thus they are passed to the cache. If you now abort the tx the invalid
> objects still in cache. Think this is a bug.
> Thanks for the test case, reproduce the problem. Will check in a fix ASAP.
Is this fix going to be available in the final 1.0 version coming out in
1 or 2 days?
Thanks,
Jair Jr
>
> regards,
> Armin
>
> >
> >>Interesting problem, please let me know if you can reproduce it.
> >
> >
> > I was able to reproduce the problem in the above test case. I hope
it
> > helps:
> >
> > Transaction t=implementation.newTransaction();
> > t.begin();
> > PersistenceBroker broker=((HasBroker)t).getBroker();
> > Student s=new Student();
> > t.lock(s,t.WRITE);
> > s.setName("student");
> > s.setEmail("[EMAIL PROTECTED]");
> > s.setPassword("abcd");
> >
> > ((TransactionExt)t).flush();
> >
> > Criteria crit=new Criteria();
> > crit.addEqualTo("_name",s.getName());
> >
> > QueryByCriteria query=QueryFactory.newQuery(Student.class,crit);
> >
> > Iterator it=broker.getIteratorByQuery(query);
> > assertSame(s,it.next());
> > assertFalse(it.hasNext());
> > t.abort();
> >
> > t=implementation.newTransaction();
> > t.begin();
> > broker=((HasBroker)t).getBroker();
> > QueryByIdentity query2=new QueryByIdentity(s);
> > boolean cacheOk=(broker.getObjectByQuery(query2)==null);
> > System.out.println("cacheOk: "+cacheOk); //cacheOk==false always
> > t.commit();
> >
> > Thanks,
> > Jair Jr
> >
> >
> >>Jair da Silva Ferreira Júnior wrote:
> >>
> >>
> >>>Hi,
> >>>I am using ojb1.0_rc5, ODMG api with OJB queries, mysql4 (innodb
> >
> > tables) in Linux Red Hat 7.3 (kernel 2.4.20-20.7).
> >
> >>>I moved from rc4 to rc5 recently and I noticed that sometimes the
> >
> > objects persisted inside an aborted transaction are still in cache when
> > another transaction is started. Please, take a look at the above code to
> > better undestand what I am saying:
> >
> >>> Transaction t=implementation.newTransaction();
> >>> t.begin();
> >>> Person e=new Person();
> >>> t.lock(e,t.WRITE);
> >>> e.setName("some exam");
> >>>t.abort();
> >>>
> >>>t=implementation.newTransaction();
> >>> t.begin();
> >>>PersistenceBroker broker=((HasBroker)t).getBroker();
> >>> QueryByIdentity query=new QueryByIdentity(e);
> >>> Person loaded=(Person)broker.getObjectByQuery(query);
> >>> boolean cacheOk=(loaded==null); //here cacheOk==false sometimes
> >>> t.commit();
> >>>
> >>>
> >>>This problem does not happen everytime. So, sometimes
cacheOk==true.
> >>>I wasn't able to reproduce this problem in a test case, but it does
> >
> > happen sometimes.
> >
> >>>This problem has never happened when I used rc4.
> >>>
> >>>Here's my cache configuration in OJB.properties:
> >>>
> >>>
> >
> > ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheDefaultImpl
> >
> >>>descriptorBasedCaches=false
> >>>
> >>>Thanks,
> >>>Jair Jr
> >>>
> >>
> >>
> >>
> >>-
> >>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]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Desperately need help with my repository
Luis Cruz wrote:
Is it possible for you to post the snip of code that does the query? My
guess is that you're doing something like this:
Here's one of my DAO methods in which the Exception is thrown:
public Collection findAllCategories() throws DataAccessException {
PersistenceBroker broker = null;
Collection results = null;
QueryByCriteria query = new QueryByCriteria(CategoryVO.class, null);
query.setStartAtIndex(1);
try {
broker = ServiceLocator.getInstance().findBroker();
results = broker.getCollectionByQuery(query);
} catch (ServiceLocatorException e) {
throw new DataAccessException("Bla Bla", e);
} finally {
if (broker != null) {
broker.close();
}
}
return results;
}
Another one that doesn't work is this ( I followed an example in the book
"Professional Struts Applications"):
public Collection findLatestAdditions() throws DataAccessException {
PersistenceBroker broker = null;
Collection results = new Vector();
Criteria criteria = new Criteria();
criteria.addOrderByDescending("id");
Query query = QueryFactory.newQuery(DocumentVO.class, criteria);
query.setStartAtIndex(1);
query.setEndAtIndex(MAXIMUM_LATESTADDITIONS - 1);
try {
broker = ServiceLocator.getInstance().findBroker();
results = (Collection) broker.getCollectionByQuery(query);
} catch (ServiceLocatorException e) {
} finally {
if (broker != null) {
broker.close();
}
}
return results;
}
Criteria criteria = new Critetia();
criteria.addEqualTo("size", someValue);
Query query = new QueryByCriteria(classToQuery, criteria);
Collection result = pb.getCollectionByQuery(query);
No i'm not. And that's the strange thing. I'm not running any query on the size
of a download.
Maybe the exception is thrown because DocumentVO doesn't have the _fileSize
attribute but it also implements the SupportItemI Interface as does DownloadVO
which has this attribute But if that was true queries on Interfaces wouldn't
be very useful, right?
If so then the problem is that OJB queries are done against objects, not
tables, there for you should change "size" to "_fileSize" or to the
corresponding bean method name (depending on the value of
PersistentFieldClass you defined in your OJB.properties file).
The PersistenceFieldClass is
org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDirectAccessImpl (default)
Hope this helps,
Luis Cruz
Thanks for your tips Luis! Any further ideas would be highly appreciated.
Patrick
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: XDoclet OJB module update
On Fri, 2 Jan 2004, Brian Sam-Bodden wrote: > Thomas, > Is there any place to find information about building the XDoclet > OJB module? You'll have to grab OJB from CVS, then you do ant docs in the OJB root directory (which will generate the documentation). You'll get the xdoclet module documentation in the target/doc folder (file xdoclet-module.html), which contains instructions on how to build the module. Though you shouldn't need to build the module anew - a binary version is in the lib folder of OJB, and the module is build against the official XDoclet 1.2 final source from the sourceforge site, so you can it together with all other modules from the XDoclet 1.2 final binary/source version. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OrderBy of ref class having same property name = problem
hi terry,
ojb always adds orderby or grouppby columns to the select columns if
they are not already there. the only thing i did in my patch was adding
an alias ojb_col_x to the automatically added columns.
the two columns in your sample are treatd as two *different* columns
because the lookup in select columns is done simply by column name, so
'bar' does not match 'foo as bar'. you'll have to use
query.addOrderBy("foo as bar")
hth
jakob
Terry Brick wrote:
Jakob,
Thanks for fixing this. It looks like the fix is possibly causing a problem in report queries.
Interestingly enough, I never even used report queries before today, but the cause of this problem
definitely looks related to the alias solution.
If one of my columns in my report query has an alias and then that alias is used in an
orderby or
a groupby, then that alias is added to my column list as a column!
For example:
query.setColumns("foo as bar");
-- work fine, unless I do something like following ---
query.addOrderBy("bar");
-- or --
query.addGroupBy("bar");
If I do this OrderBy or GroupBy, with a column alias, it adds that alias to my select columns..
The sql will come out something like...
select foo as bar, bar as obj_col1 from foos order by xx
As you can see, "bar as obj_col1" is a problem
Thanks...
--- Jakob Braeuchi <[EMAIL PROTECTED]> wrote:
hi terry,
i checked in a quick fix using column alias.
jakob
Jakob Braeuchi wrote:
hi terry,
i can reproduce the problem and i posted it to the developer list:
http://article.gmane.org/gmane.comp.jakarta.ojb.devel/4830
thanks for the testcase.
jakob
__
Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003
http://search.yahoo.com/top2003
-
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]
