The UniVerse admin guide has extensive documentation on locks (which is
actually quite clear), including Deadlock management...UV deadlock
manager can actually be turned off, it is doesn't work well for how your
application works (or if has weird locking requirements or poorly
implemented as is more likely the case.


-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of John Hester
Sent: Friday, 12 December 2008 7:34 AM
To: [email protected]
Subject: RE: [U2] Universe locking

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Susan Joslyn
> Sent: Thursday, December 11, 2008 10:10 AM
> To: [email protected]
> Subject: [U2] Universe locking
> 
> Hi group.
> 
> I guess anyone can tell I'm working on Universe a lot more 
> than usual right
> now.   Current struggle is with locks.  I'm pretty sure a 
> lock-up-and-hang
> situation is occurring when a user's nested process is locked 
> against its
> own parent.  In Unidata there is a UDT.OPTIONS setting that 
> can tell it not
> to do that.  I was reading the universe manual and . well, 
> there's a lot of
> stuff in there about escalating and sharing and managing  
> your deadlocks (I
> thought you just didn't comb at all and that's how you got 
> dreadlocks? No
> management required?  What?  Oh DEADlocks.  Never mind.)  I 
> honestly don't
> really understand what deadlocking is but - does anyone know 
> how to tell
> universe to ignore locks by the same user/port/session, like 
> on unidata?

A deadlock occurs when 2 different processes each need a lock the other
has.  If not for the UV deadlock daemon, both processes would hang
indefinitely.  The deadlock daemon will choose one of the processes and
kill it after some length of time (I'm not sure how the choice is made).
You can avoid this situation at the programming level by insuring that
all programs lock files in the same sequence, but that's easier said
than done.  One method we've used to mitigate it is adding a READVU line
to a "master lock" file in programs that access a lot of the same files
and lock large numbers of records.  Nothing is ever actually written to
the master lock file, but a lock is held against a master ID (inventory
ID in our case) until the other detail level locks are released.

As far as locks by the same user/port/session - AFAIK, you can't have a
conflict unless you spawn a new process, which you can only do with the
PHANTOM command.  Once you have a new process, I think UV will see it as
unique and you will have the same locking issues you would have with
separate user sessions.  I don't know that there's any way around that.
All the same opportunities for inconsistent data still exist regardless
of whether the processes were initiated by the same or different users.

-John
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/

Reply via email to