Compression and exclusive state locks?

[MartinAmeskamp]

Hi, we have a customer with around 50 concurrent editors on ArcGIS 10.0 SP5 (yes, I know), and Oracle 11.2.04. Editing is done using work order versions, and the number of versions is near the number of users. The typical versions lives a couple of hours: gets created off DEFAULT, edited, passed on to a QC person, and then gets reconciled, posted, and deleted by a dedicated service (ArcGIS Server + Java ArcObjects API). A (reasonably) full compress is done every night after shutting down various services, and this typically gets the number of states very close to the number of open versions.

We keep seeing the effect, though, that a large number of version have a very long state lineage (hundreds), and the state tree (viewed with GDBT) looks a bit like a palm tree: A long (hundreds) linear chain of states with no versions pointing to them.

After looking into the situation, I found that there seem to be a large number of exclusive state locks:In one specific instance, most users have few shared state locks, but some users have 20 to 30 exclusive state locks each.

I assume that these exclusive locks have something to do with the long uncopmpressed chains of states, and the question is. Where do they come from? What can I do with ArcMap to generate 20 exclusive state locks??

This seems to be a recurring problem, so I'm interested in finding out how it comes about. As night, when theer are no users, the database behaves as expected and compresses quite nicely...

Thanks, Martin

[SamuelTompsett]

Hi Martin,

Maybe the following would help out.

35794 - Obtain a listing of user processes and locks from a geodatabase when there is no ArcSDE serv...

A shared state lock is acquired anytime a versioned representation of a dataset is open in ArcGIS. - Meaning anytime anyone is actively editing something

Geodatabase locks—Help | ArcGIS for Desktop

-Sam

[MartinAmeskamp]

Hi Sam,

thanks for your reply. The shared locks I understand - it's the exclusive locks I'm having trouble with. I haven't checked yet whether they're all very close together, i.e. created by one edit session, or whether they're distributed all over the state tree.

Martin

[SamuelTompsett]

Hi Martin,

Exclusive locks are also outlined in the documentation I pasted above. In general, they arent anything to worry about unless you start seeing persistent exclusive locks.

-Sam

[BlakeTerhune]

Are you forcibly disconnecting all users when you do the compress? Are you also reconciling the versions that are still left (if any) before the compress?

[MartinAmeskamp]

Hi Blake,

no, we don't forcibly or otherwise disconnect users, and yes, we reconcile versions using a background python script. The point is not to achieve a full compress, but rather to keep performance acceptable during the day.

Martin

[MartinAmeskamp]

Hi Sam & Blake,

thanks for taking the time to look at this. I've done some more looking at states, state locks etc. and came to the conclusion that I have to look elsewhere for a solution to my palm tree problem (long persistent chains of uncompressed states). The exclusive locks are all very recent and belong to recent states in open edit sessions. Specifically, they are nowhere near my "problem area". In short, they are perfectly harmless, like Sam said.

Martin

[BlakeTerhune]

What I was getting at is that if you disconnect all users when you do the reconcile and compress, it might help eliminate the long state lineages because nobody will be able to lock up the states in an ArcMap session.

[MartinAmeskamp]

True - that's what happens at night. The problem is that these long chains reappear during the day, and I have yet to find out why compress doesn't collapse them. Most days, they're relatively harmless with 200-300 states, but we recently had over 1000 states in one of those chains, meaning that almost every version has a state lineage of over 1000 states - that slows down things significantly.

Martin

[BlakeTerhune]

Since you can't clear them up over night, maybe it's just compounding again during the day. I would try to get everyone disconnected when you do your maintenance and see if that makes a difference.