Yes you can still use it all that means is they added a Obsolete Attribute.
It would be nice if they added comments like this from here to the documentation
StartTransaction() has a huge overhead for small operations – about 100 times slower that Open and Close style for entity read operations totaling less than about 80 in a single transaction. StartOpenCloseTransaction() can be easily substituted for StartTransaction() calls, thus regaining your performance while maintaining the same code layout. I should mention that StartTransaction() really comes into it’s own on large datasets, quickly becoming 1000+ times quicker than Open and Close for write operations
Well, I have some issues with that.
First, the overhead of 'small operations' is generally insignificant and not perceptible to a user. In other words, the fact that AcTransaction is 100 times slower than the open/close mechanism with 80 operations means little or nothing because that takes a fraction of a second either way.
Second, using the Open/Close methods directly is dangerous in certain usage contexts. One is when multiple objects are being opened simultaneously, verses serially opening and closing one object at a time. If you are opening many objects and need to keep them open simultaneously, you would need either a separate using() construct for each opened object or a separate try/finally for each open object, because if you didn't do either, some of the objects may never be closed if an exception causes the code to exit while the objects are still open.
The second context where Open()/Close() can be dangerous is when it is used with
using(), and the opened object(s) are being modified. When you use a
using() constrct to dispose an object that was opened via ObjectId.Open(), disposing the object causes its Close() method to be called, causing any pending changes to be committed. But with using(), the call to Dispose() will occur regardless of whether the code terminated normally or prematurely as a result of an exception.
When you use a standard transaction in the same context, the transaction's Abort() method is called by Dispose() if an exception causes the code to exit before the call to Commit() was reached, and any pending changes made to objects that were acquired via the transaction are rolled back by aborting the transaction (which is essentially the same as using UNDO/Begin/End followed by the U command).
So, for read-only access, the Open()/Close() mechanisms can be used directly and safely, but when opening and modifying objects, one must be very mindful of what happens when an open DBObject is closed as a result of a call to its Dispose() method, and whether any changes made to it should be committed or cancelled if an exception was raised while the object was open, and possibly before all changes were made to it.
The OpenCloseTransaction (
StartOpenCloseTransaction()) is designed to allow the open/close mechanism to be used like a transaction, and also guarantees that if the transaction is aborted, all objects are closed via a call to their Cancel() method (rather than their Close() method). So, the OpenCloseTransaction serves two basic purposes, which is to ensure that any objects that are opened are closed when the transaction is either aborted or committed, and second, to ensure that cancel() is called on all opened objects when the transaction is aborted.
Here is a simple example that shows the dangers of using Open() and Close() directly to modify objects:
public static class Class1
{
public static void BuggyOpenCloseUsage()
{
Document doc = Application.DocumentManager.MdiActiveDocument;
PromptEntityOptions peo
= new PromptEntityOptions
( "\nSelect a circle: "); PromptEntityResult per = doc.Editor.GetEntity( peo );
if( per.Status != PromptStatus.Ok )
return;
// error checking for entity type intentionally omitted
using( Circle circle = per.ObjectId.Open( OpenMode.ForWrite ) as Circle )
{
circle.LayerId = SymbolUtilityServices.GetLayerZeroId( doc.Database );
circle.Radius = 100.0 / 0.0; // < DivideByZeroException
}
}
}
In the above snippet, first the circle's layer is changed to layer 0, then we intentionally cause a divide-by-zero error to simulate an exception that might occur while the object is open. When the exception causes the using() construct to call Dispose() on the opened Circle, the change to the circle's layer is committed, because DBObject.Dispose() calls DBObject.Close(), rather than DBObject.Cancel(). That means the object was left in a partially-modified state, and all changes made to it were not rolled back because transactions aren't being used.
If a standard or OpenClose transaction had been used in this same context, the same error would cause all changes made to the circle to be cancelled.