Seems like I have attempted something like you suggest, and I had no luck. I
believe that it has something to do with Java references. I'm sure that it
wouldn't work as you have it written because pObj and pObjUpdate are both
referencing the same object. When you change one, the reflects that change.
Another problem with your suggestion is that when you lock the object OJB
takes a 'snapshot' of it. On commit it compares the object to the
'snapshot'. If there is no difference, it would NOT update because nothing
has changed. So even if you changed your reference to point to a different
object, with the same values it would be unchanged.
Here's a thought...... make a copy of the object to be updated. Change
something in the original, then lock it. Copy the changed attribute from the
object copy and commit. In this way the object HAS changed between the lock
and the commit. The problem is......what do you change. In a generic case
you would not have a common attribute (other than perhaps the oid which you
would NOT want to be changing!!!). It appears (and this is the path that we
have taken) that you need to lock the object when you retrieve it. Hold the
lock while the user makes changes, and finally commit (or rollback) once the
user finally completes their action.
If anyone has any other suggestions, I would certainly like to hear them.
Dave Derry
----- Original Message -----
From: "Olaf" <[EMAIL PROTECTED]>
> Hi Walid,
>
> I also have got a singleton class with a similar store() code than you.
> At least in singleVM mode it works fine for me, but in C/S mode I have
> problems, but I don't know yet if it's because of the singleton and/or
> the upcast to Object. Will try more today.
>
> Writing update code in a singleton class is difficult, because the
> object has to be locked BEFORE it is changed:
>
> tx.begin();
> pobj = query(persistentObject.class); // put a real query here
> tx.lock(pobj, tx.WRITE);
> pobj.setName("Walid"); //change the Name here
> tx.commit();
>
>
> Probabably you could play around with something like this, but I DID NOT
> TRY THIS:
>
> pobj = query(persistentObject.class); // put a real query here
> pobjUpdate = pobj;
> pobjUpdate.setName=("Walid);
> update(pobj, pobjUpdate);
>
> public void update(Object toBeUpdated, Object update) {
> tx.begin();
> tx.lock(toBeUpdated, tx.WRITE);
> toBeUpdated = update; //the object is exchanged for a new one.
> tx.commit();
> }
>
> /olaf
>
>
>
> Walid Ahmed wrote:
>
> >Hi!
> >
> >I've spent now 5h on finding out the following behaviour:
> >There is a significant difference between storing new objects and storing
existing but edited objects.
> >The latter seems to work only if properties are edited between the
transaction beginning and the commitment. Right??
> >I wanted to use the following method in a singleton ControlClass.
> >
> > public void store(Object toBeStored) {
> > Database db = odmg.getDatabase(null); // the current DB
> > Transaction tx = null;
> > tx = odmg.newTransaction();
> > tx.begin();
> > tx.lock(toBeStored, tx.WRITE);
> > tx.commit();
> > }
> >
> >So in one case I put in a newly created Object (OID==0 ?) and in another
case its an object that I retrieve from DB to change some properties.
> >The first case works fine, but in the second I just get the following:
> >
> >[org.apache.ojb.broker.singlevm.PersistenceBrokerImpl] DEBUG:
getObjectByIdentity de.itconcept.bbs.server.company.data.Address{21}
> >
> >But there is no UPDATE executed against the DB.
> >Sometimes (!) its followed by a debug output about what SELECT statement
was used for getting an Address.
> >
> >What can I do?? I'dont want to move the transaction outside of the store
function. Are there possibilities to store Objects without beginning and
comitting transactions?
> >Can I use an alternative method than tx.lock(toBeStored,tx.WRITE) ?
> >Why does db.makePersistent(toBeStored) does'nt work either?
> >
> >Thank You all for helping
> >
> >Walid
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
