Thank you for your help, Regards, Sylvain
On Wed, 26 Jan 2005 14:16:22 +0100, Armin Waibel <[EMAIL PROTECTED]> wrote: > Hi, > > Sylvain ~ wrote: > > I finally found what was wrong... > > > > In fact it is very simple, I was using a database-repository.xml > > template from a struts tutorial, and there was a static declaration of > > the cache implementation, thus overriding OJB.properties settings, and > > it was set with emptyCacheImpl... so that's why crossreferenced > > objects resulted into stack overflow since this cache doesn"t make > > anything. I set it back to CachePerBroker and it performs well. > > > > doh! Never use copy paste ;-) > > > > However, the "strange part" is that it used to work without any > > problem in one-threaded test cases before the patch ... > > > > to tell the truth, I don't know. > > > > Now I can use crossreferenced objects correctly, but now my concern is > > more on performance side, because all my database objects are > > crossreferenced objects and are, of course, not retrieved by the same > > PB, so my question is : > > > > Is there a global cache implementation that will be shared by all > > persistence brokers and thus can be accessed by many threads ? > > > > You can use each global cache in a multithreaded environment. The only > problem will be caused by shared object instances. The possibility of > "dirty-reads" and "stolen data" when multiple threads modify the same > object at the same time. > > http://db.apache.org/ojb/docu/guides/objectcache.html#ObjectCacheDefaultImpl > > In next version of OJB (1.0.2) a first version of an two-level cache > will be included, which will avoid problems described above. You can try > latest from CVS (get the OJB_1_0_RELEASE branch, HEAD is OJB 1.1). To > generate the docs you need Apache Forrest (0.6 or higher) installed. > > > > And finally, what about these cache implementation we can find in > > javadoc in the org.apache.ojb.broker.cache package ? > > ObjectCachePerClassImpl > > ObjectCacheSoftImpl > > > > Please see javadoc and source code. Think they aren't smarter then the > other implementations. > > regards, > Armin > > > Best regards. > > > > On Wed, 26 Jan 2005 12:43:20 +0100, Armin Waibel <[EMAIL PROTECTED]> wrote: > > > >>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] > >> > >> > > > > > > --------------------------------------------------------------------- > > 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]
