Concurrent edit sessions on same non-versioned geodatabase

1956
2
Jump to solution
10-10-2020 04:26 PM
MKF62
by
Occasional Contributor III

I have two python scripts that are scheduled to run at 12:00 AM everyday that edit different feature classes in the same non-versioned enterprise geodatabase. I haven't yet run them at the same time because I'm not sure if two edit sessions being launched within minutes of each other on the same database is possible, and I don't want to screw with any existing data until I have a better answer. Basically, each script calls this exact same piece of code (same workspace):

#Start editing session
arcpy.AddMessage("Starting editing session...")
try:
   editor = arcpy.da.Editor(collector_db_con)
   editor.startEditing(False, False)
   editor.startOperation()
except:
   raise EditingErr(traceback.format_exc())‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

I looked at information about locks and it appears that locks apply to individual datasets so there shouldn't be conflicts there since the feature classes being edited by the two scripts are different, but I would like more clarity since editing sessions are initialized on the entire workspace. I can foresee getting errors.

Before anyone suggests I merge the two scripts together, there are reasons they are separate and I will not be merging them. If two edit sessions cannot be done on the same workspace simultaneously, then I will just schedule them differently.

Tags (1)
0 Kudos
1 Solution

Accepted Solutions
MKF62
by
Occasional Contributor III

Thanks for the suggestion - I ended up doing that first and when I found I could have simultaneous edit sessions on the same workspace, I went a step further to make sure that "update row" could be done simultaneously on different feature classes in the same workspace. I made two identical python files using a different feature class in each and set them up to run on task scheduler to launch at the same time; worked just fine. Then I tried putting two editors in the same script with one editor stopping editing before the other:

arcpy.env.workspace = os.path.join(aPro_db_con, "CollectorSpatialData_CollectorWriter.sde")

cc = "CollectorSpatialData.DBO.HbTestLine"
fc = os.path.join(arcpy.env.workspace, cc)

cc2 = "CollectorSpatialData.DBO.HbTest"
fc2 = os.path.join(arcpy.env.workspace, cc2)

editor = arcpy.da.Editor(arcpy.env.workspace)
editor.startEditing(False, False)
editor.startOperation()

editor2 = arcpy.da.Editor(arcpy.env.workspace)
editor2.startEditing(False, False)
editor2.startOperation()

with arcpy.da.UpdateCursor(fc, ['TestField']) as uCursor:
    for row in uCursor:
        row[0] = 1
        try:
            uCursor.updateRow(row)
        except:
            print(traceback.format_exc())
del uCursor
editor.stopOperation()
editor.stopEditing(True)

if editor2.isEditing == True:
    with arcpy.da.UpdateCursor(fc2, ['TestField']) as uCursor:
        for row in uCursor:
            row[0] = 1
            try:
                uCursor.updateRow(row)
            except:
                print(traceback.format_exc())
    del uCursor
    editor2.stopOperation()
    editor2.stopEditing(True)
    del editor2
print("Finished.")‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

This is where the problems begin. In reality, my two scripts that edit the same workspace are not identical and one will finish editing in that workspace before the other one; if an edit session ends on that workspace in one script, will it still keep the edit session in the other script alive? Using the script above, the answer is seemingly yes; when I checked editor2.isEditing it was True, but when I updated the row and ran editor2.stopOperation() I received this error:

editor2.stopOperation()
SystemError: <built-in method stopOperation of Workspace Editor object at 0x000002473EEF8FC0> returned NULL without setting an error

My guess is that edit session is now "confused" by the other edit session stopping in the same process, thus it will not be able to save edits. To test my theory further, I went back to my two identical scripts that launch at the same time. I wondered if the fact that they're launching in entirely separate processes made a difference. I added time.sleep(60) after instantiating the edit session in one of them to make the script pause for a full minute. That full minute gave the other script a chance to finish editing and stop the edit session on the workspace before the other script starts the update the row on a feature class in its own edit session on that same workspace. Both scripts completed without error.

Conclusion: If the edit sessions are launched in different processes, then they should be able to run simultaneously without erroring, regardless if one finishes editing before the other.

View solution in original post

0 Kudos
2 Replies
JoeBorgione
MVP Emeritus

Can't you just test it manually?  Depending on your IDE, just run lines 4,5 & 6 in the console.  Once that session is open, start a second session but with: 

editor2 = arcpy.da.Editor(collector_db_con)
editor2.startEditing(False, False)
editor2.startOperation()

If that does not toss an error you are golden.  If it does toss an error, it's time to formulate plan B...

That should just about do it....
0 Kudos
MKF62
by
Occasional Contributor III

Thanks for the suggestion - I ended up doing that first and when I found I could have simultaneous edit sessions on the same workspace, I went a step further to make sure that "update row" could be done simultaneously on different feature classes in the same workspace. I made two identical python files using a different feature class in each and set them up to run on task scheduler to launch at the same time; worked just fine. Then I tried putting two editors in the same script with one editor stopping editing before the other:

arcpy.env.workspace = os.path.join(aPro_db_con, "CollectorSpatialData_CollectorWriter.sde")

cc = "CollectorSpatialData.DBO.HbTestLine"
fc = os.path.join(arcpy.env.workspace, cc)

cc2 = "CollectorSpatialData.DBO.HbTest"
fc2 = os.path.join(arcpy.env.workspace, cc2)

editor = arcpy.da.Editor(arcpy.env.workspace)
editor.startEditing(False, False)
editor.startOperation()

editor2 = arcpy.da.Editor(arcpy.env.workspace)
editor2.startEditing(False, False)
editor2.startOperation()

with arcpy.da.UpdateCursor(fc, ['TestField']) as uCursor:
    for row in uCursor:
        row[0] = 1
        try:
            uCursor.updateRow(row)
        except:
            print(traceback.format_exc())
del uCursor
editor.stopOperation()
editor.stopEditing(True)

if editor2.isEditing == True:
    with arcpy.da.UpdateCursor(fc2, ['TestField']) as uCursor:
        for row in uCursor:
            row[0] = 1
            try:
                uCursor.updateRow(row)
            except:
                print(traceback.format_exc())
    del uCursor
    editor2.stopOperation()
    editor2.stopEditing(True)
    del editor2
print("Finished.")‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

This is where the problems begin. In reality, my two scripts that edit the same workspace are not identical and one will finish editing in that workspace before the other one; if an edit session ends on that workspace in one script, will it still keep the edit session in the other script alive? Using the script above, the answer is seemingly yes; when I checked editor2.isEditing it was True, but when I updated the row and ran editor2.stopOperation() I received this error:

editor2.stopOperation()
SystemError: <built-in method stopOperation of Workspace Editor object at 0x000002473EEF8FC0> returned NULL without setting an error

My guess is that edit session is now "confused" by the other edit session stopping in the same process, thus it will not be able to save edits. To test my theory further, I went back to my two identical scripts that launch at the same time. I wondered if the fact that they're launching in entirely separate processes made a difference. I added time.sleep(60) after instantiating the edit session in one of them to make the script pause for a full minute. That full minute gave the other script a chance to finish editing and stop the edit session on the workspace before the other script starts the update the row on a feature class in its own edit session on that same workspace. Both scripts completed without error.

Conclusion: If the edit sessions are launched in different processes, then they should be able to run simultaneously without erroring, regardless if one finishes editing before the other.

0 Kudos