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,

You also could have one orphaned state lock that is holding up a whole entire lineage. It would be important to reconcile/post all versions, delete all versions, then make sure each and every lock is out of the geodatabase.

OBJECT_LOCKS

LAYER_LOCKS

STATE_LOCKS

TABLE_LOCKS

After that, compress to state 0.

-Sam

[MartinAmeskamp]

Hi Sam,

I'm afraid that's not an option. We get a chance to delete all versions about twice a year. As I tried to say above, we still get the database into a reasonable state every night - ~ 1 state per version, no chains, short state lineages, so mornings are fine. The chain effect keeps building up during the day. The oldest locked state right now (3 pm local time) is from yesterday morning.

Martin

[SamuelTompsett]

Hi Martin,

Understandable. Do you have any services or anything that would aquire that lock at 3PM? You should also be able to track who is acquiring that lock. The sde_id column in the state_locks table corresponds to the sde_id column in the process_information table. At least you can start tracking who specifically it is.

-Sam

[RebeccaStrauch__GISP]

Also make sure that the actual Oracle database is not being backed up (server/network side) which most likely could create a lock (if that was mentioned in the docs already, my apologies ..I didn't read thru them yet).