Problem Upgrading to APEX 3.2 – “Resource /i is Locked by Name”

In my last post I wrote about a problem I had using a DOCTYPE in themes running on APEX 3.1.2. I also commented that the underlying cause of the problem had been fixed in the upcoming 3.2 release that was being previewed at apex.oracle.com. When 3.2 was released last week I hastily downloaded it and set about upgrading my 3.1.2 installation. A lot of my current work depends on the included fixes and I was anxious to get back to working on my new themes. Unfortunately I encountered an obscure error during the upgrade that proved hard to track down: “ORA -31110: Action failed as resource /i is locked by name”.  After some digging I finally found the cause of the error and, more importantly, the solution.

The error occurred during the later stages of the upgrade, when trying to copy the images directory on “/i” using:

@apxldimg c:\apex\apex_3.2

The output from this process was:

ERROR at line 1:
ORA -31110: Action failed as resource /i is locked by name
ORA -06512: at "XDB.DBMS_XDB", line 242
ORA -06512: at line 44

The error description is a little vague and typical searches for more details provided even less help:

Oracle Error :: ORA -31110

Action failed as resource string is locked by name.

Cause

Delete/Rename failed because one of the children is locked.

Action

Do lockdiscovery to find the lock and delete it.

Further searches on “lockdiscovery” hinted at the problem lying with WebDAV, the subject of my last post. Obviously some aspect of the WebDAV connection to /i I had set up in Dreamweaver was locking resources in /i and preventing them from being modified. Unlike Windows Web Folders, Dreamweaver WebDAV connections do support the LOCK and UNLOCK features of WebDAV that facilitates mutliple users working with shared files and folders. But, according to Dreamweaver documentation, LOCK and UNLOCK are only used when the Check In/Check Out feature of Dreamweaver is used. As I don’t use Check In/Check Out I was a little puzzled as to why any of my files would be locked, but on closer inspection it appears that when using a Dreamweaver WebDAV connection, Check In/Check Out is automatically applied, even when using Get/Put.

Without knowing which specific files or folders were locked I went to the root of my Dreamweaver “site” (mapped to /i/themes/) and did Undo Check Out from the right-click menu. After this I tried running apxldimg again and the update was successful.

Although this issue is probably very specific to my set up, I’m sure at some point someone else will come across this problem and need to go through the same steps I did. Hopefully this information will save them some time.

Stephen

Stephen Blair is a freelance artist and designer. He has created numerous websites including those selling his own vector clipart and APEX themes.

4 Responses to “Problem Upgrading to APEX 3.2 – “Resource /i is Locked by Name””

  • John Scott says:

    Hi Stephen,

    I’m assuming you’re also uploading and storing your own images/css/jaavscript etc under the /i/ location.

    I would really recommend against that, as you’re exposing yourself to wiping out those resources when you come to upgrade APEX (as you’ve discovered), instead I’d recommend creating your own location for any custom resources and using that.

    Just my thoughts,

    John.

    • Hi John,

      Your assumption that I am storing images/css/javascript etc. under /i/ is correct. But of course, all of these files are created and stored on the local file system and “put” to /i/ via the WebDAV connection, hence the “locked” resource issue that is the subject of this post. Working this way means theme files can easily be restored en masse following an APEX upgrade and negates the risk of them being wiped out for good.

      Stephen

  • John Scott says:

    Hi Stephen,

    I was really referring to the fact that I’m usually against storing your own custom things under /i/ as that is where the standard APEX installed files live.

    For any of our custom resources we tend to setup something like /ci/ this way our custom themes can refer to /ci/css/sidebar.css etc and we don’t need to worry that we’ll ever accidently wipe out our own things if we upgrade APEX, it also helps to make a better separation between the ‘core’ things in APEX and our own custom resources etc.

    Hope this clarifies,

    John

    • That sounds like good advice John. Thank you.

Comments can no longer be submitted.