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.

[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.

[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]

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.)

[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?

[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]

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

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]

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]

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.