more details...
alertAPI.clearLockForObject(alert.getEntity(), LockableObject.WRITE_LOCK);//release write lock
//then check it out
alert = alertAPI.checkout(alert.getEntity(), TIME);//successful!!!
//remove alertuserprops
alertAPI.removeUserProperties("remark");

The result is the data dissapear from the table for a while, then it come back!



Someone shed some light on me?
Thanks!

It resolved.
Thanks any way.

Hi,

I have almost the same problem as qunfengw.

During trap filter processing, I have to checkout a MO to update its properties in DB.

The first time the trap is issued, everything works properly :

1 - I checkout the MO (as I said, I need a write lock to update the MO)
Everything goes fine.
I get the MO with a valid write lock.

2 - I update the MO using TopoAPI.updateObject(MO, false, true).
According to WebNMS documentation the write lock on the MO is released on update completion.

3 - The same device issues the trap once again (a minute later or so).
The trap processing starts normally.
The problem is : I am unable to checkout that MO.
I get a TimeoutException.
And that's all.
As if a write lock already exists for the MO.
Or as if a write lock had not been released previously (while using "TopoAPI.updateObject(MO, false, true)").

Since it seems there is no means to know which process holds a lock on a specified MO, I feel a little bit lost.

When you say, qunfengw, your problem is resolved, could you please explain what happened?
Did you discover something abnormal?

Any help would be greatly appreciated.

Thanks and regards,
Johanna.

My problem is a little different with yours. But I think you should unlock your MO after the step2

2 - I update the MO using TopoAPI.updateObject(MO, false, true).
According to WebNMS documentation the write lock on the MO is released on update completion.

Please give a try.

Hello qunfengw,

I have already had a try at this (even if it doesn't seem right to me).
It didn't work either.

Anyway : the TopiAPI "updateObjet(x,x,true)" method is supposed to release any lock upon completion (which means : I should not have to "unlock" the object by myself).

Eventually, your source code gave me an idea.
Here is what I do : once the update done (still having the "dealWithLock" parameter set to true), I use the "clearLockForObject" for WRITE_LOCK on the MO.

It works but I must say I don't like to do this - I should not have to do this (still according to WebNMS documentation).

Johanna.

Are you sure the problem resolved?
This method can't work in my application, you'd better refresh you DB front to see if the data is persistent.

more details...
alertAPI.clearLockForObject(alert.getEntity(), LockableObject.WRITE_LOCK);//release write lock
//then check it out
alert = alertAPI.checkout(alert.getEntity(), TIME);//successful!!!
//remove alertuserprops
alertAPI.removeUserProperties("remark");

The result is the data dissapear from the table for a while, then it come back!

The first time the trap is issued, everything works properly :

1 - I checkout the MO (as I said, I need a write lock to update the MO)
Everything goes fine.
I get the MO with a valid write lock.

2 - I update the MO using TopoAPI.updateObject(MO, false, true).
According to WebNMS documentation the write lock on the MO is released on update completion.

3 - The same device issues the trap once again (a minute later or so).
The trap processing starts normally.
The problem is : I am unable to checkout that MO.
I get a TimeoutException.

Johanna :

Could please post the exact code snippet for the above impl., and complete exceptions trace (or log files) ??

Pandya !