.NET

Reply
*Matt
Message 1 of 3 (116 Views)

Best practice for transactions

116 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
transaction.
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
layer;
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
places.

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

My concern is just that a lot of transactions take a lot of time
Member
brnac196
Posts: 4
Registered: ‎09-11-2007
Message 2 of 3 (116 Views)

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
foruma000256
Posts: 216
Registered: ‎01-28-2004
Message 3 of 3 (116 Views)

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
Try
dlock = ThisDrawing.LockDocument
'do something to generate an objectid for the
'function to return
trans.Commit()
Catch ex As System.Exception
Dim aex As New System.Exception("Error finding or creating a new " & "" & " EmptyFunction. ", ex)
Throw aex
Finally
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
Announcements
Do you have 60 seconds to spare? The Autodesk Community Team is revamping our site ranking system and we want your feedback! Please click here to launch the 5 question survey. As always your input is greatly appreciated.