GP service error: "The current version does not support editing..."

[Anonymous User]

I have a GP service published that updates a series of features then publishes a pdf. Several of the feature classes have attachments, so it is necessary to open an edit session when updating them. The script works, both within Arcmap and from the GP service.

But, after using the GP service several times (typically when several users start using it), I keep getting an error in the server manager logs:

Error: The current version does not support editing (base, consistent, or closed) [An open transaction was detected. All user transactions must be closed prior to StartEditing.].

Can anyone help troubleshoot how or why this error message keeps appearing? I'm assuming that somehow two users are calling the GP service at the same time and somehow it is causing a lock situation. Or maybe someone is accessing that feature layer at the same time (there are feature services that access the same layers) Restarting the gp service and feature service appears to fix the issue, until it occurs again.

Are there any script examples or advice on how a script should handle opening closing edit sessions when other instances of the script might be doing the exact same thing?

[BasWest1]

Hi Paul, dit you already resolve this issue? We have similar problems.

[Anonymous User]

Hi Bas

No, not resolved yet. Getting very frustrating for us!

To try to rectify it, I even went through the scripts and replaced the use of arcpy insert and update cursors with using arcrest to call the rest api. The theory there was that somehow the insert/update cursors, which *did* regularly open and close edit sessions, were somehow not closing one properly (even though I couldn't see how that could happen), and that using pure rest api calls for any edits would allow arcgis server to manage those concurrent edits. But I've still had the same error occur. It even happened late last night, at a time when I was testing the arcrest scripts and knew 99.9% that I was the only one using the system, so I knew there was no other edit sessions open (e.g. in arcmap etc).

I'm using ags 10.4.1 on aws with a SQL server enterprise geodatabase.

Can you share a bit about your setup and workflow to see if any similarities perhaps?

cheers,

-Paul

[BasWest1]

We are on ArcGIS for server 10.3 with an Oracle enterprise geodatabase.

We also have this problem with a featureclass with attachments (and another related table). These are exclusively being edited by rest calls (through the Javascript API). Sometimes there is no problem for days, and then it occurs again. Last time when this problem occured our DBA could confirm that the the open transaction was in the attachment table and that the database was waiting for the client Arcsoc to send some kind of signal to close the transaction, but was not receiving any (as far as I understood).

So I guess the problem seems to be caused by something related to the adding of attachments through the REST API.

[Anonymous User]

Interesting. No clear similarities between your situation and ours then. i.e. 10.3 vs 10.4.1, Oracle vs. Sql Server, and I've had it happen to feature classes that didn't have attachments enabled. And, initially, I was using arcpy insert and update cursors (e.g. NOT the rest api) whereas you are exclusively using rest calls.

I'm still a bit stumped I'm afraid....

[Anonymous User]

Hi Paul,

Try to increase 
The maximum time a client can use a service: as per transaction compilation time as average one.
You can also need to configure number if instance for GP services.
Some settings are not optimise.

[Anonymous User]

Hi Avinash.

Thanks for the reply.

The default 'maximum time a client can use a service' is 600 seconds, or 10 minutes, which should be plenty of time to execute the GP tasks I have in place. Typically they complete in around 15-20 seconds.

The number of instances is set just to min 1 max 2, but a) I've seen the problem occur when I'm the only one using the service so it wasn't under huge load and b) I thought the idea was that in the services were maxed out then a new request would either wait or timeout. i.e. it shouldn't cause a lock scenario such as it is.

Would appreciate any further discussion or insights into how it works.

Cheers,

-Paul

[CarlosKrefft]

I contacted ESRI premium support about this. They said they knew of it, it's a bug and has been fixed in 10.5.1:
BUG-000100553: Receiving "An open transaction was detected. All user transactions must be closed prior to StartEditing" error in the ArcGIS Server logs when applying online edits with a non-versioned feature service

What I don't understand is this was working fine before and all of a sudden stopped. There must be a work around to resolve this like republishing the service, re-installing server, something because it's not an issue out of the box.

[Anonymous User]

Hi Carlos

Thanks for your comment, that's interesting to hear. Can you post a link to the bug report? I can't seem to find any reference to 'BUG-000100553' when searching on the ESRI support site, and am not sure if I'm looking in the right place. 

I have raised this with our local ESRI distributor previously but they haven't mentioned this so probably not aware of it and it would be good to be able to pass the info on to them.

Thanks.

[CarlosKrefft]

I don't have a link. They just gave me that bug information and description. 

I did seem to have resolved my problem. I simply republished my service and all is okay now. I can add the attachments and I no more of those errors are logged.

Good Luck!