How to override edit locks

I'm writing a WLS开发者_如何学JAVAT 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.

You could try setting a wait period and timeout:

startEdit([waitTimeInMillis], [timeoutInMillis], [exclusive]).  

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?

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 cancelEdit command that you could run before you startEdit. 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.

1. Locate the Change Center in the upper left corner of the Administration Console.
2. Click Take Lock & Edit.
3. Make your configuration changes.
4. In the Change Center, click Activate Changes. Not all changes take effect immediately. Some require a restart (see Use the Change Center).

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 startEdit that will log the exception's stack trace, but do nothing else. And then rely on the edit call 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.