如何覆盖编辑锁
我正在编写一个 WLST 脚本来部署一些 WAR 和 EAR。但是，脚本会间歇性地超时，因为它似乎无法获得编辑锁定（该脚本是许多其他脚本链的一部分）。我想知道，有没有办法覆盖或停止服务器上的任何当前锁定？这只是一个临时解决方案，但为了时间的考虑，暂时就这样吧。
谢谢。
I'm writing a WLST script to deploy some WAR's and an EAR. However, intermittently, the script will time out because it can't seem to get an edit lock (this script is part of a chain of many other scripts). I was wondering, is there a way to override or stop any current locks on the server? This is only a temporary solution, but in the interest of time, it will do for now.
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您可以尝试设置等待时间和超时：
其他脚本是否出错，导致会话锁定？您可以尝试在这些周围添加异常处理。 ，如果您在管理控制台中启用了“自动获取锁定”并且使用管理控制台，那么有时如果您同时运行脚本，即使您没有进行“需要锁定”的更改，也可能会导致问题。
此外 ，您是否对链接脚本使用相同的用户？
You could try setting a wait period and timeout:
Are other scripts erroring out, leaving the session locked? You could try adding exception handling around those. Also, if you have 'Automatically acquire lock" enabled in the Admin Console and you use the admin console sometimes it can cause problems if you are running scripts at the same time, even though you are not making "lock-requiring" changes.
Also, are you using the same user for the chained scripts?
在 WLST 中，您可以传递一个数字作为参数来获得独占锁。这允许脚本获取与管理员从控制台锁定时使用的常规锁不同的锁。它还可以防止同一脚本的两个实例相互干扰。
然而，这会产生复杂的变更合并场景，最好（通过流程）避免这种情况。
Oracle 有关配置锁的文档可以在此处。
或者，如果您希望脚本暂时解除任何现有的锁定，而不管待处理的更改如何，您也可以从控制台禁用更改管理，以最大程度地减少造成的不便。
WLST 还包含您可以在
startEdit之前运行的cancelEdit命令。希望这些选择之一能够成功！Within WLST, you can pass a number as a parameter to gain an exclusive lock. This allows the script to grab a different lock than the regular one that's used whenever an administrator locks from the console. It also prevents two instances of the same script from stepping on each other.
However, this creates complex change merge scenarios that are best avoided (by processes).
Oracle's documentation on configuration locks can be found here.
Alternatively, if you want the script to temporarily relieve any existing locks regardless of the pending changes, you may as well disable change management from the console, minimizing the inconvenience caused.
WLST also contains the
cancelEditcommand that you could run before youstartEdit. Hope one of these options pan out!要从其他管理员处获取配置更改锁定：
如果另一管理员已拥有配置锁，则会显示以下消息：另一用户已拥有该锁。您需要等待锁被释放，或者获取锁。
管理控制台。
立即生效。有些需要重新启动（请参阅使用更改
中心）。
To take the configuration change lock from another administrator:
If another administrator already has the configuration lock, the following message appears: Another user already owns the lock. You will need to either wait for the lock to be released, or take the lock.
Administration Console.
effect immediately. Some require a restart (see Use the Change
Center).
只要您以管理用户身份运行 WLST，您就应该能够使用 edit() 命令跳转到现有的编辑会话 - 我已经使用两个管理员用户（其中一个在管理控制台中）进行了快速测试，并且一个使用 WLST，它似乎工作正常 - 我可以看到 WLST 解释器内管理控制台会话中的更改。
您可以在对
startEdit的调用周围放置一个非常简单的异常处理程序，该处理程序将记录异常的堆栈跟踪，但不执行其他操作。然后依靠edit调用将您弹出到更改会话中。如果另一个脚本已经启动了编辑会话并且期望能够提交该更改会话本身，那么依赖于此将会很棘手 - 您将在多次调用中遇到异常和不可靠的行为。
As long as you're running WLST as an administrative user, you should be able to jump into an existing edit session with the edit() command - I've done a quick test with two admin users, one in the Admin Console, and one using WLST, and it appears to work fine - I can see the changes in the Admin Console session inside the WLST interpreter.
You could put a very simple exception handler around your calls to
startEditthat will log the exception's stack trace, but do nothing else. And then rely on theeditcall to pop you into the change session.Relying on that is going to be tricky though if another script has started an edit session and is expecting to be able to commit that change session itself - you'll be getting exceptions and unreliable behaviour across multiple invocations.