nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

File geodatabase debugging lock problem, what are "rd" locks?

AlexanderGray

Hi,
I am currently debugging a problem with locks on a file geodatabase for some functions that were done programmatically. I notice there are ".sr" locks, which are schema locks, i.e. not change to the schema allowed. There are ".ed" locks, edit locks, no edits on the data allowed. There is another lock file, ".rd" lock, this one I am puzzled with. Does anyone know what rd locks are? The only mention it would be some unreleased cursor. Still I would like to know if it puts an edit lock on the featureclass.

Najděte více příspěvků označených jako

Accepted answers

All comments

LanceShipman

Is this on Linux or Windows (version)?

What version of ArcGIS? What product (Engine, Desktop, Server)?

On Windows the lock files are created as "delete on close", so even if the application crashes that files will delete. Windows takes care of it. The only reason a lock file would stay in existence if another process (process, not user) has the lock or if you pulled the pug on the PC. If the lock file is still in existence, the process will normally delete it and create a new one.

MaryPasse-Smith

I am having a different but similar problem. I teach in a lab, and occasionally have lock files that persist AFTER ArcGIS is closed, the user is logged off, the computer is rebooted, they are NOT within a file (or any) geodatabase (simply shapefiles that are, often, being joined to something but not always) in a lab setting on a virtual drive, usually. They are so numerous now they are hurting the ability of my students to work--they cannot edit their files, and no way can I save them such that they will work. They are (evidently) SR locks. Nobody can delete them, not even our IT people (I think they had SOME luck in Linux, finally, but it is becoming a real problem). Does anyone know how I can prevent my students from creating these in the first place (may be that they are crashing out, but once they log off, should they not go away??) and/or how to deal with them once they exist? Please help!

AlexanderGray

The file geodatabase is not designed to do that. It is designed do handle multiple readers and one editor. RDMS geodatabase are specifically designed to do that and esri has SDE for that. I am not sure what the status for multi-editor on a sql express geodatabase, technically it should work but it may have been clamped down to push users towards ArcGIS server solutions.

SebastianKrings

hey thanks

is there a way to share locks?
two different processes want to insert/ edit data of the same featureclass within the same geodatabase parallel.
Well I could make this manually due to a loop until the lock is released and the other process get the lock and so on. but is there an esri method doing like this?
so one shared lock all processes can edit/ insert data without exceptions because arcgis is queuing the locks etc.

LanceShipman

A different process can still read a file with a edit lock. It�??s only with a write lock that a read is not possible. To improve performance buffering was added to file geodatabase at 10.1? Prior to 10.1 buffering was not active. At 10.1 a write lock will only be taken out every 1000 features or when flush is called when the inserts are performed.

SebastianKrings

hi

thx for this summing answer.
But I still have a question refering the ED and WR Lock.

WorkspaceEdit.StartEditing() //creates an ED-Lock.
IFeature.store();
WorkspaceEdit.SaveEdits() and WorkSpaceEdit.SopEdting(true) //will create an WR lock for a very short time i guess and then deletes the ED-Lock and the WR Lock as well?

FeatureClass.insert() //creates an IFeatureCursor and an WR-Lock. This WR lock is deleted when the object is not used any more.

Am I able to speed this behavior up? At the moment I am trying IFeatureCursor.Flush and IFeatureCurso = null but I cannot see the lock released faster. This one will be deleted when the method within I use the insertCursor has finished.
Could a COM-Releaser be useful? The thing is, it could be possible that after using the insertCurso the method still is not ready or has to wait for other threads...

I know that an worspace edit-session should be used to store one feature. ESRI documentation says that when having three ore more features for better performance an insertCursor shall be used. Now I wonder if the edit session, calling the save edits only at the ends, were a way to hold an WR-Lock shorter than having the insertCursor still opend. What I do not know at this moment is if the ED-Lock also blocks other processes from working with the Map/Geodatabase.

Thanks.

LanceShipman

RD-Lock - Read Lock
SR-Lock - Schema Lock
WR-Lock - Write Lock
ED-Lock - Edit Lock

Locking is by process, not user.

A write lock will be held until a Insert Cursor goes out of scope. In an edit session a edit lock is taken out. A write lock is only taken out on save edits. A read lock can not be taken out during a write lock.

SebastianKrings

hi

unfortunately the source-question has not been answered.
So I will ask in advance.

What are these locks all. Is there in ESRI documentation any explanation?

What is the full name of these abbreviations?
What will they lock each?
Which operations (e.g.) will arise such locks?

Known locks by us (feel free to explain further existing locks):
RD-Lock
SR-Lock
WR-Lock
ED-Lock

Some keywords we can imagine these locks are affecting:
Share-Read-Lock
Read-Data(set)-Lock
Refresh-Data-Lock (because refreshing the map created an RD-Lock)
Write-(Read-)Lock (by an insertionCursor (FeatureClass.Insert())
Edit-(Data-)-Lock (by an editSession (IWorkspaceEdit.StartEditing()))

It would be grateful if someone coul illuminate this topic.
Thanks.

LanceShipman

The only way a lock file will persist is if a process is maintaining it.The lock files are created as "delete on close" so the operating system will delete them when the creating process closes. Is your file geodatabase local or on a network disk? What version of ArcGIS are you using?

AlexanderGray

In my case I had two ArcMap sessions that need to edit the data in turn (arcmap1 check out, arcmap 2 edit, arcmap1 clean and check-in). I changed the workflow to have one session do all the edits (edit, clean and check-in.) Aside from that, I would suggest using SQL express if you can (in my case this is not practical for various reasons.)

JenniferPhillips

I am having the same problem with "rd" locks in our file geodatabase. I understand that multiple people cannot edit at one time, and that one person cannot edit while others are viewing the same layers. But we have an issue where once someone is in the map with the layer, and then closes out, it keeps the "sr" lock active, and sometimes an "rd" lock too. This prevents one user from being able to edit that layer, even though everyone else is closed out. Typically, that person will have to restart their computer to get the lock to finally release. This is a big problem, as you shouldn't have to have everyone restart their computer in order to edit.

Did you come up with a solution on this?

Thank you!

AlexanderGray

Further developments, I discovered that having Joins with the option keep only matching records (inner join) in a an open arcmap session puts the "rd.lock" on the tables and featureclasses involved in the join. I am not sure why but they put an edit lock on the tables and featureclasses. Regular left joins are ok.

Připojte se k diskusi

Přihlášení členové mohou přispívat, sledovat aktualizace a další. Jste tu noví? Zaregistrujte si bezplatný účet.

Rychlé odkazy

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.