Best practice for transactions

117 Views, 2 Replies
11-23-2006 01:36 AM
What is the best practice to use transactions?

Not a real-world example:
I have a utility that creates a layer. I encapsulates the creation in a
I have another that adds an entity to the database, also in an transaction
I have a dialog where at some point lines (on specified layers, maybee newly
created) are added to the database
And finally i create a command where the user selects something and fires
upp the command.

How many transactions should i start?
One? Two or all four?

If i skip the form-example and just pick a point and adds a line on a new
Is it better to start three transactions (one to pick, one to create layer
and one to add the line) or is it better to use the same transaction in all

Of course i see that are different cases where different approach are

My concern is just that a lot of transactions take a lot of time
4 Posts
0 Kudos
Registered: ‎09-11-2007
Post 2 of 3

Re: Best practice for transactions

04-18-2008 05:08 AM in reply to: *Matt
I have the same problem with my app.

I deliver to each function (which are doing something) Transaction, Editor or Database (if needed).

public void DoSomething(
Editor ed,
Database db,
Transaction tr
// code here
// cone here
Distinguished Contributor
216 Posts
1 Kudo
Registered: ‎01-28-2004
Post 3 of 3

Re: Best practice for transactions

05-02-2008 04:14 PM in reply to: *Matt
This VB.net function I use over and over to create a generally fool proof (as if there is such a thing) method of structuring a transaction based routine.

I have db, thisdrawing, and ed defined as public variables that i resuse like mad, wouldn't necessarily recommend that approach.

'Using' just helps with stronger garbage collection, but it can be troublesome at times, because objects defined inside dissapear when you end using.

I also inclosed a basic error trapping try/catch block that throws the error up when found (this stops the rest of the routine between try and catch from processing, so you may want to handle your errors in different ways and at different places)

You can nest transactions a lot (like 256 i think) before AutoCAD will die. JUST BE SURE TO DISPOSE EACH ONE...
Everytime you enter the line trans.commit() will fire off autocad events, so if your listening you may need to ignore the events during processing. (if ignore = true then exit sub)

Document locking helps keep your palettes/forms and autocad application playing nicely.

All these lines I tend to write over and over by force when debugging my code. When I skip them for convenience, AutoCAD is sure to tell me about it.

Public Function EmptyFunction() As ObjectId
Dim dlock As DocumentLock = Nothing
Dim oid As ObjectId = Nothing
Using trans As Transaction = _ db.TransactionManager.StartTransaction
dlock = ThisDrawing.LockDocument
'do something to generate an objectid for the
'function to return
Catch ex As System.Exception
Dim aex As New System.Exception("Error finding or creating a new " & "" & " EmptyFunction. ", ex)
Throw aex
If Not trans Is Nothing Then trans.Dispose()
If Not dlock Is Nothing Then dlock.Dispose()
End Try
End Using
Return oid
End Function
Post to the Community

Have questions about Autodesk products? Ask the community.

New Post
Are you interested in helping shape the future of the Autodesk Community? To participate in this brief usability study, please click here. Your time and input is greatly appreciated!