versioning (long transactions- short transactions)

[MohamedIsmael]

Hi. In versioning i want to know what is (long transactions- short transactions) meaning and what is the difference between them.

[GlenterpriseUK]

Hi @MohamedIsmael,

Explaining versioning and all details that are involved in the Long vs. Short transactions requires an entire book to explain 😊

I will give you a brief overview of both:
- Short transactions are considered quick edits that you make in a database and happen instantly and cause a lock on the data for a moment. An example can be when you want to update a single record in the database and save it straight away.

- Long transactions are what are used on an enterprise geodatabase when you are doing editings in multiple versions where you can make edits that stay in your version for a certain duration, review them and only when you are ready to reconcile and post them back to the main version you can.

In short, short transactions are quick edits, long transactions let you work over time without causing locks or blocks to other users.

Regards,

Glen

[DerekLaw]

Hi @MohamedIsmael,

FYI, this article on traditional versioning might also be useful.

Versioning 101

Hope this helps,

[DavidSolari · Accepted solution]

Edit management is tricky to keep track of in ArcGIS because you have multiple types of "transactions":

• Database transactions/file locks: These are the fundamental locks that everything else is built upon. Proper databases (EGDBs, File GDBs, Mobile GDBs etc.) can start and stop transactions of various lengths depending on how you edit them, these limit how other users can write data to the same DB while they're in effect. EGDBs run on full relational database engines so transactions are usually kept as short as possible to avoid locking up other users, this is why your ability to save or undo edits are heavily limited when you work with them directly. The file system DBs only allow one active writer so they can keep a transaction going much longer. Other file types try to behave like File/Mobile GDBs by creating lock files during edits if possible.
• Edit sessions: These open a transaction/lock and only release the lock when you finish your edits. GDBs will keep a stack of your edits to allow you to undo, redo, and fully discard the edits before saving. Other file types are usually more limited in how granular the edit tracking goes. You can also have an edit session with an EGDB, but only if you use ...
• Versions: Concurrent streams of edits that are merged into one EGDB object. Every individual edit uses a short transaction and the ability to undo/redo/discard involves manipulating the table data through these short transactions, with various version control mechanisms used to isolate these potentially incomplete edits from other versions. This would be the "have your cake and eat it too" option if it weren't for the extra complexity brough by reconciling, posting, conflict detection etc. as well as making the underlying DB tables less performant than a straight list of features.

My advice is to avoid thinking of "short" vs. "long" transactions and instead think about how you need to manage a piece of data over the long term: who needs to edit it, do they need to do so concurrently, is it worth giving them access to an undo stack in exchange for adding version management etc. If you field calculate 1 million records directly against an EGDB feature class with no undo enabled you're technically doing a "short" transaction, but you can probably guess that you're locking the database up far longer than if you move one point in a "long transaction" branch version.

[MohamedIsmael]

Thank you