Sam, the best way to go about getting your changes discussed and eventually committed, is to create a bug report/enhancement request at http://bugzilla.exolab.org, attach any changes you are proposing. In terms of the discussion, it can either take place as part of the bug report or at this very mailing list. Personally, I think that it should be part of the bug report, but in general it's down to preferences.
Looking forward to your suggestions .. ;-). Werner On Fri, 9 Jul 2004 14:45:59 -0400, Sam Maloney wrote: > >Hi Pat, > >Due to the tight time-lines and the fact I just moved (and don't have Internet >setup at my place until next week), I have yet to do so for a few patches to >Castor I have done in order for our application to function 100%. > >Sometime next week (Tue is Internet install day) I can start breaking out each >fix into separate patches and normalizing the test cases based on the Castor >test framework. > >At that point I can even apply the patches to 0.9.5.3 and test that they still >happen (which they all appear to). > >Also; who on the JDO side of Castor development has experience / vested >interest in the way the depends attribute works (or more so, how not having a >depends works)? I would like to start a dialog, as I have a proposed change >for it (already coded and tested) that functions basically the same as now, >but is more powerful in that it allows handling of more complex schemas in a >very clean way still. > >Later, >Sam > >On July 8, 2004 05:53 am, Patrick van Kann wrote: >> Hi Sam, >> >> Did you file a bugzilla report about this? >> >> http://bugzilla.exolab.org/ >> >> If not, it would be great and much appreciated if you could file one, >> including your patch and some test cases using the Castor Testing >> Framework. It looks like the example client code below would be a starting >> point for a test case if you have not already made one. >> >> Cheers, >> >> Patrick >> >> -----Original Message----- >> From: Sam Maloney [mailto:[EMAIL PROTECTED] >> Sent: Thu 7/8/2004 12:11 AM >> To: [EMAIL PROTECTED] >> Subject: Re: [castor-dev] Lock conflict >> >> >> Hi Tomasz, >> >> I found and fixed recently a bug that caused that exact error. >> >> The bug would happen in this situation: >> >> Any tree of mapped objects where there is at least one 1:N relationships to >> a dependant object. ie: >> >> Store <-->> Register (depends=Store) >> >> These can even be empty (minus the Pk). All that is needed to cause this is >> a 1:N relationship where the Ns are dependant on the 1 AND the >> parent/reverse relationship (in the map) from the N to the 1 MUST be there >> for the bug to happen. >> >> In any case with such a setup (which is most likely very common, and >> appears to be your case), the bug would happen simply by spawning two or >> more threads concurrently that fetch the same object at the same time, even >> both in the same access mode (exclusive or dblocked). >> >> ie: >> ----- >> public static void testLockProblem() { >> Runnable runner = new Runnable() { >> public void run() { >> _testLockProblem(); >> } >> }; >> >> new Thread(runner, "test runner 1").start(); >> new Thread(runner, "test runner 2").start(); >> } >> >> public static void _testLockProblem() { >> try { >> db.begin(); >> db.load(Store.class, new Long(0), Database.DbLocked); >> >> // Wait to simulate processing, thus holding the lock, thus enabling >> // concurrency to happen for sure. >> Object obj = new Object(); >> synchronized(obj){ >> try { >> obj.wait(1000); >> } catch (InterruptedException e) { >> } >> } >> >> db.commit(); >> } catch (Exception e) { >> throw new RuntimeException(e); >> } >> } >> ----- >> >> If you run the above test on a simple tree as described above and this >> problem happens every single time you run the test, then most likely it is >> the exact same problem. >> >> If you confirm this is the case, then msg the list again and we can discuss >> the patch. It is tested and works perfect, however it is an unofficial >> patch against version 0.9.5.1. So mention which version you are using in >> your reply. >> >> Later, >> Sam >> >> On July 7, 2004 06:14 am, Tomasz Piontek wrote: >> > Hello, >> > >> > I would be very grateful if anyone could explain to me why the following >> > code complains about the "LockConflict"? >> > I make only one query in Exclusive mode, so why the QueryResults tries >> > to lock the object again and causes LockConflict? >> > >> > I read the documentation and in my opinion the conflict is caused >> > because the query was made (as it was specified in Exclusive mode) and >> > when the object is loaded by QueryResults it is done in default mode (I >> > didn't specified "access" attribute in mapping file) which is Shared one. >> > >> > Could anyone tell me what did I wrong. I want to query from my code >> > objects as well in ReadOnly as in Exclusive mode. I don't want to use >> > Shared mode. >> > >> > It's not a productive code, I simplified my code as it was possible. >> > >> > public void manual() >> > { >> > JDO jdo = null; >> > Database db = null; >> > QueryResults result = null; >> > try { >> > jdo = new JDO(); >> > jdo.setDatabaseName( "grms-devel_jobreg" ); >> > jdo.setConfiguration( "./etc/jobreg_database.xml" ); >> > db = jdo.getDatabase(); >> > db.begin(); >> > OQLQuery query = db.getOQLQuery("select job from >> > grms.jobreg.JobInfo job where job.id=$1"); >> > query.bind("JOB_ID0"); >> > result = query.execute( Database.Exclusive); >> > JobInfo job = null; >> > if( result.hasMore()) >> > job = (JobInfo)result.next(); >> > >> > //some updates >> > System.out.println( "JOB_NAME = " + job.jobId); >> > db.commit(); >> > db.close(); >> > } catch ( Exception e) { >> > e.printStackTrace(); >> > } >> > } >> > >> > The executions finishes with following exception: >> > >> > org.exolab.castor.jdo.PersistenceException: Lock conflict: attempt to >> > load object of type grms.jobreg.JobInfo with identity 1 in two different >> > locks modes (exclusive and non exclusive) in the same transaction >> > at >> > org.exolab.castor.persist.TransactionContext.load(TransactionContext.java >> >:6 27) at >> > org.exolab.castor.persist.TransactionContext.load(TransactionContext.java >> >:5 55) at org.exolab.castor.persist.ClassMolder.load(ClassMolder.java:764) >> > at org.exolab.castor.persist.LockEngine.load(LockEngine.java:356) at >> > org.exolab.castor.persist.TransactionContext.load(TransactionContext.java >> >:6 49) at >> > org.exolab.castor.persist.TransactionContext.load(TransactionContext.java >> >:5 55) at org.exolab.castor.persist.ClassMolder.load(ClassMolder.java:793) >> > at org.exolab.castor.persist.LockEngine.load(LockEngine.java:356) at >> > org.exolab.castor.persist.TransactionContext.load(TransactionContext.java >> >:6 49) at >> > org.exolab.castor.persist.QueryResults.fetch(QueryResults.java:229) >> > at >> > org.exolab.castor.jdo.engine.OQLQueryImpl$OQLEnumeration.hasMore(OQLQuery >> >Im pl.java:627) at >> > org.exolab.castor.jdo.engine.OQLQueryImpl$OQLEnumeration.hasMore(OQLQuery >> >Im pl.java:610) at >> > grms.tests.jobreg.RepositoryThreads.manual(RepositoryThreads.java:198) >> > at >> > grms.tests.jobreg.RepositoryThreads.main(RepositoryThreads.java:212) >> > >> > and the mapping file more less is: >> > >> > <?xml version="1.0" encoding="UTF-8"?> >> > >> > <mapping> >> > <description>Castor generated mapping file</description> >> > >> > <class name="grms.jobreg.JobInfo" identity="dbId" key-generator="MAX"> >> > <description>Default mapping for class >> > grms.jobreg.JobInfo</description> <map-to xml="job-info" >> > table="grms_repository_job"/> >> > <field name="dbId" type="int"> >> > <bind-xml name="db-id" node="attribute"/> >> > <sql name="job_rep_job_id" type="integer"/> >> > </field> >> > >> > >> > <field name="id" type="java.lang.String"> >> > <bind-xml name="id" node="element"/> >> > <sql name="job_id" type="char"/> >> > </field> >> > >> > <field name="fileDirs" type="grms.jobreg.InOutFileDir" >> > collection="array"> >> > <bind-xml name="out-files" node="element"/> >> > <sql many-key="job_rep_job_id"/> >> > </field> >> > >> > <field name="jobHistory" type="grms.jobreg.JobHistory" >> > collection="array"> >> > <bind-xml name="job-history" node="element"/> >> > <sql many-key="job_rep_job_id"/> >> > </field> >> > >> > <field name="jobNotifications" type="grms.jobreg.JobNotification" >> > collection="array"> >> > <bind-xml name="job-notifications" node="element"/> >> > <sql many-key="job_rep_job_id"/> >> > </field> >> > </class> >> > >> > <class name="grms.jobreg.JobHistory" identity="dbId" >> > key-generator="MAX" depends="grms.jobreg.JobInfo"> >> > <description>Default mapping for class >> > grms.jobreg.JobHistory</description> >> > <map-to xml="job-history" table="grms_repository_history"/> >> > <field name="dbId" type="integer"> >> > <bind-xml name="db-id" node="attribute"/> >> > <sql name="job_rep_history_id" type="integer"/> >> > </field> >> > >> > <field name="homeDirectory" type="java.lang.String"> >> > <bind-xml name="home-directory" node="element"/> >> > <sql name="home_directory" type="char"/> >> > </field> >> > >> > <field name="jobInfo" type="grms.jobreg.JobInfo"> >> > <bind-xml name="job-info" node="attribute"/> >> > <sql name="job_rep_job_id"/> >> > </field> >> > >> > </class> >> > >> > >> > <class name="grms.jobreg.InOutFileDir" identity="dbId" >> > key-generator="MAX" depends="grms.jobreg.JobInfo"> >> > <description>Default mapping for class InOutFile</description> >> > <map-to table="grms_repository_filedir"/> >> > >> > <field name="dbId" type="integer" direct="true"> >> > <bind-xml name="db-id" node="attribute"/> >> > <sql name="job_rep_filedir_id" type="integer"/> >> > </field> >> > >> > <field name="jobInfo" type="grms.jobreg.JobInfo" >> > direct="true"> <bind-xml reference="true" node="attribute"/> >> > <sql name="job_rep_job_id"/> >> > </field> >> > </class> >> > >> > >> > <class name="grms.jobreg.JobNotification" identity="dbId" >> > key-generator="MAX" depends="grms.jobreg.JobInfo"> >> > <description>Default mapping for class >> > grms.jobreg.JobNotification</description> >> > <map-to table="grms_repository_notif"/> >> > <field name="dbId" type="integer"> >> > <bind-xml name="db-id" node="attribute"/> >> > <sql name="job_rep_notif_id" type="integer"/> >> > </field> >> > >> > <field name="jobNotificationUsers" >> > type="grms.jobreg.JobNotificationUser" collection="array"> >> > <bind-xml name="job-notification-users" node="element"/> >> > <sql many-key="job_rep_notif_id"/> >> > </field> >> > >> > <field name="JobInfo" type="grms.jobreg.JobInfo"> >> > <bind-xml reference="true" node="attribute"/> >> > <sql name="job_rep_job_id"/> >> > </field> >> > </class> >> > >> > <class name="grms.jobreg.JobNotificationUser" identity="dbId" >> > key-generator="MAX" depends="grms.jobreg.JobNotification"> >> > <description>Default mapping for class >> > grms.jobreg.JobNotificationUser</description> >> > <map-to table="grms_repository_notif_dn"/> >> > <field name="dbId" type="int"> >> > <bind-xml name="db-id" node="attribute"/> >> > <sql name="job_rep_notif_dn_id" type="integer"/> >> > </field> >> > >> > <field name="JobNotification" type="grms.jobreg.JobNotification"> >> > <bind-xml reference="true" node="attribute"/> >> > <sql name="job_rep_notif_id"/> >> > </field> >> > >> > </class> >> > </mapping> >> > >> > I will be very grateful for any hints how to solve the problem and for >> > information what is the casue of it. >> > >> > All the best, >> > Tomasz >> >> ----------------------------------------------------------- >> If you wish to unsubscribe from this mailing, send mail to >> [EMAIL PROTECTED] with a subject of: >> unsubscribe castor-dev > > > >----------------------------------------------------------- >If you wish to unsubscribe from this mailing, send mail to >[EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev > ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
