Stats

  • Locked Locked
  • Replies 5
  • Subscribers 143
  • Views 15528
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

VLS lock manager auto-refresh without DM

caver456

Hello - we're trying to write a lock manager which shows the user what cells are currently write-locked in a certain library, by whom, and when the lock was created.  We've got most of this in place already, including an option to release the write lock on a cell that you yourself have write-locked.

We are not using any Design Management system - just a plain-ol OA library on disk that multiple people point to.

As it is now, you have to manually refresh the locked file listing by clicking a button in the lock manager GUI.  It would be excellent to get rid of that need: is there a good way to have the lock manager automatically refresh whenever a locked cell becomes unlocked, or when a previously unlocked cell gets locked by any user running on any node?

ddRegTrigger("PreObjAccess" 'stuff) works for a single user's session; you would have to make sure that each user is running that trigger (and its callback function) and you'd also have to work some form of IPC to get them to notify each other of changes.

Linux has some options like 'watch', which could also push out to all IPC listeners and would only have to run on one node, but it would be nice to not have a constantly running background application - but maybe it's not that computationally expensive?

Is there some lower-level linux file system trigger that sends notifications on file/dir changes, which IPC could listen for, or even better, is there actually an already-existing SKILL function to do said listening?

What's your recommended course of action for this type of listening?

Thanks

Parents
  • Andrew Beckett

    A few comments:

    1. First of all, I hope this "lock release" is being done by just closing (or making readonly) the data in the current session. Forcibly releasing a lock when something has genuinely got it open for edit is rather dangerous as then both processes would think they have an exclusive lock and data could then be lost.
    2. Generally there's no need to do lock recovery because if the process with the lock is no longer running, the stranded lock recovery mechanism will be able to recover it (it contacts the machine which had the lock, and checks if that process is still running). The only times this fails is if the machine which previously had the lock is no longer accessible or that clsbd/oaFSLockD is no longer running - normally those start as soon as virtuoso is launched on a machine.
    3. There's no way to watch a file in Virtuoso. You'd either need to use a timer to regularly poll - potentially expensive - or something similar to what you were suggesting - launching an application which communicates via IPC back to the session you launched from and then you have some other infrastructure to check that data. Seems like a bit of an over-engineered solution to me though when a refresh button is probably simpler...
    4. The library manager and also the navigator in the layout editor already have the ability to show the lock status (the Navigator you can add a column called "Lock Status" into the hierarchy tree display). So you can at least see who has got things locked in the hierarchy you're using

    Regards,

    Andrew

Reply
  • Andrew Beckett

    A few comments:

    1. First of all, I hope this "lock release" is being done by just closing (or making readonly) the data in the current session. Forcibly releasing a lock when something has genuinely got it open for edit is rather dangerous as then both processes would think they have an exclusive lock and data could then be lost.
    2. Generally there's no need to do lock recovery because if the process with the lock is no longer running, the stranded lock recovery mechanism will be able to recover it (it contacts the machine which had the lock, and checks if that process is still running). The only times this fails is if the machine which previously had the lock is no longer accessible or that clsbd/oaFSLockD is no longer running - normally those start as soon as virtuoso is launched on a machine.
    3. There's no way to watch a file in Virtuoso. You'd either need to use a timer to regularly poll - potentially expensive - or something similar to what you were suggesting - launching an application which communicates via IPC back to the session you launched from and then you have some other infrastructure to check that data. Seems like a bit of an over-engineered solution to me though when a refresh button is probably simpler...
    4. The library manager and also the navigator in the layout editor already have the ability to show the lock status (the Navigator you can add a column called "Lock Status" into the hierarchy tree display). So you can at least see who has got things locked in the hierarchy you're using

    Regards,

    Andrew

Children
  • caver456
    in reply to Andrew Beckett

    The lock release is hopefully doing it 'the right way': (sorry the 'source code' tool doesn't seem to work - it doesn't bother to turn line breaks into <br>)

    cv=dbOpenCellViewByType(libName cellName "layout" "" "r") ;; leaves it in write mode if already open

    ; note, even if the window banner doesn't look like it's descended, it may be descended
    ; and therefore would not match for either displayCellView or geGetCellViewWindow
    winMatch=geGetCellViewWindow(cv)
    if(winMatch then
    hiRaiseWindow(winMatch)
    hiSetCurrentWindow(winMatch)
    printf("Matching window: %L\n" winMatch)
    _leChangeEditMode("r")
    else
    printf("Sorry, no matching window for %L %L layout.\n" libName cellName)
    w=geOpen(?lib libName ?cell cellName ?view "layout" ?mode "r")
    _leChangeEditMode("r")
    hiCloseWindow(w)
    )

    Never noticed that in the navigator - that's pretty handy.  The one we're working on just shows a plain list (actually a report / table) of all cells in the library that are locked.  With hundreds of cells in the library it's mainly just a space-saver vs the built-in solutions, and lets you see all the locks in one concise display.

    It would be nice to add a context menu with 'notify me when this cell is freed' and 'request/nag'.  Maybe auto-refresh / poll would not be needed unless you set 'notify' on one or more cells. 

  • caver456
    in reply to Andrew Beckett

    also some more relevant comments from the code:

    ; make sure we don't delete any unsaved edits!
    ; cell is in some window at top level (not descended)? --> raise that window then _leChangeEditMode("r")
    ; otherwise, open the cell in a new window in edit mode, then _leChangeEditMode("r")
    ; (this is safer than using dbReopen which says it will immediately discard edits, though it
    ; actually appears to preserve edits even though changing to read mode; presumably the user
    ; is prompted to save the cell on virtuoso exit
    ;
    ; It should be fine to also call _leChangeEditMode("r") for the currently viewed cell even if it
    ; is the result of edit-in-place. In this case it wouldn't match for displayCellView or
    ; geGetCellViewWindow, but, should match for ...

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.