You'd load an object using Database.Readonly and then want to upgrade it to Database.Shared? This is tricky because Database.Readonly mode does not associate the object with a transaction. I don't think you can do that. Another transaction can certainly load the same object type using Database.Shared and manipulate the object. So if you passed the object id around you can achieve this. It would be best if you can devide your app into parts that only do reading and use Database.Readonly then use Database.Shared when you think you might want to change the object. The long transaction support is kinda shaky in castor so I wouldn't rely on it. It works only if the object is in the cache, as soon as the object leaves the cache funny things start happening. You have to leave the cache in unlimited mode for things to work, which might cause you to run out of memory... ----- Original Message ----- From: Richard Lawson <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, January 31, 2002 6:42 PM Subject: Re: [castor-dev] LockNotGrantedException
> Thanks, > Would that allow other transactions using Database.Shared to updgade their > lock if they try to load the same object? > The API docs don't have much to say on the matter. > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 31, 2002 6:35 AM > To: [EMAIL PROTECTED] > Subject: Re: [castor-dev] LockNotGrantedException > > > > You don't need to mark the object as read only in the mapping file. The > below works > > results = oql.execute(Database.ReadOnly); > > > > > > Richard Lawson > > <Richard.Lawson@St To: [EMAIL PROTECTED] > > eeves.NET> cc: > > Subject: Re: [castor-dev] > LockNotGrantedException > 01/25/2002 06:43 > > PM > > Please respond to > > castor-dev > > > > > > > > > Thanks, > I gave it a spin. I have a general method to retrieve objects by their id > so > I commented out the Database.begin() and Database.commit() lines and got a > new error: "No transaction in progress for the current thread > org.exolab.castor.jdo.TransactionNotInProgressException". > > I don't have the luxury of marking some objects read-only in the mapping > file. Most times i want to read a product object, but sometimes I want to > update it. Maybe I'm missing the point. > - rich > > > -----Original Message----- > From: dom [mailto:[EMAIL PROTECTED]] > Sent: Friday, January 25, 2002 2:06 PM > To: [EMAIL PROTECTED] > Subject: Re: [castor-dev] LockNotGrantedException > > > for objects that you know you're only going to read you could load them > outside of a transaction all together > by specifying READ ONLY access. that way your objects will not use any > locks > > -dom > ----- Original Message ----- > From: Richard Lawson <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Friday, January 25, 2002 5:53 PM > Subject: [castor-dev] LockNotGrantedException > > > > Hi folks, > > I've inherited a project that uses JDO to persist objects to the database > > and do the marshalling/unmarshalling between the java objects and the > > DocumentFragements that represent them. I'm new to this, but it seems a > > pretty good strategy so far. > > > > The problem is that I have deeply nested collections and quite often the > > users get LockNotGrantedException when trying to commit objects. > > I understand that this can happen when there are read locks in other > > instances and your transaction tries to aquire a write lock. Is is > possible > > that the read locks are not being released? > > > > Also, in the cases when I know that the user will only be reading and I > have > > created the xml for their UI, how can i make sure that the object is > > destroyed and the lock released? > > > > Any help would be a godsend. - thanks in advance > > > > Richard Lawson > > email: [EMAIL PROTECTED] > > > > ----------------------------------------------------------- > > 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 > > ----------------------------------------------------------- > 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
