Hi Sylvain,

I don't know why it happens, maybe I don't understand the problem. The method

public StorableObject get(Class objectClass, Integer pk)

should return the full materialized object as long as the auto-retrieve settings are "true" and no proxy was used (e.g. OJB materialize a Room object with all User, each User with it's Room,...). This should not cause an endless loop when lookup the object, because you are using an session cache.

Is the stack trace loop within OJB or is your app involved?
If you invoke the "get(Class objectClass, Integer pk)" code in an test case, do the same error happen? If yes, the problem was caused by OJB. In this case please send me your test and I will try to fix it.



>>>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.

hmm, the first time you retrieve an Room or an User object the full object graph should be materialized, so it doesn't matter if different threads try to read object elements.
Again please try to write an test case to reproduce the problem (if you think it's a multi-threaded problem run two threads in your test).


regards,
Armin


Sylvain ~ wrote:
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.<init>(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 = 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]




--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to