This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
I have an unusual situation. From just one of my computer on the network, when I perform a TransactopnScope database update, the TransationScope throws en exception on the scope.Complete() command, but surprisingly, th data is actually saved into the database I though if the Transaciton faied then Lightspeed would roll back the save? The error I receive from the scope.Complete() is ERROR :: Cannot access a disposed object. Object name: 'Transaction'. Logger: ResortManager.General.Exceptions.ExceptionHandling Thread: 1 Date: 2010-08-25 15:05:58,495 NDC: (null) System.ObjectDisposedException: Cannot access a disposed object. Object name: 'Transaction'. at System.Transactions.Transaction.get_TransactionInformation()
at Mindscape.LightSpeed.UnitOfWork.(Object , TransactionEventArgs )
at System.Transactions.TransactionCompletedEventHandler.Invoke(Object sender, TransactionEventArgs e)
at System.Transactions.InternalTransaction.FireCompletion()
at System.Transactions.TransactionStatePromotedCommitted.EnterState(InternalTransaction tx)
at System.Transactions.TransactionStatePromotedBase.ChangeStatePromotedCommitted(InternalTransaction tx)
at System.Transactions.DurableEnlistmentDelegated.Committed(InternalEnlistment enlistment)
at System.Transactions.SinglePhaseEnlistment.Committed()
at System.Data.SqlClient.SqlDelegatedTransaction.SinglePhaseCommit(SinglePhaseEnlistment enlistment)
at System.Transactions.TransactionStateDelegatedCommitting.EnterState(InternalTransaction tx)
at System.Transactions.TransactionStateDelegated.BeginCommit(InternalTransaction tx, Boolean asyncCommit, AsyncCallback asyncCallback, Object asyncState)
at System.Transactions.CommittableTransaction.Commit()
at System.Transactions.TransactionScope.InternalDispose()
at System.Transactions.TransactionScope.Dispose()
at ResortManager.BL.StockTools.TransferStock(StockTransferData stockTransferData)
at ResortManager.UI.UserControls.Inventory.StockTransfer.CmdOkClick(Object sender, EventArgs e)
There are two issues here, one, why am I getting this error if the save has completed, and two, why when I get this error is the transaction not rolling back the batabase saves? I would welcome any advise on this. This system handles financial transactions, so it is vital the transaction handling works as expected. Thanks |
|
|
Hi, does anyone have any idea why the data is still being persisted to the database even though the Transaction is throwing an error. By my understanding, if all the LS oens, updates, saves etc. are performed within a TransactionScope, then if the Transaction does not complete sucessfully, the data should not be persisted, ot am I missing somehting. Thank |
|
|
Jeremy is having a look at why the exception is thrown though it may be down to this .NET Framework bug: Regarding why the data is still persisted, I believe the reason is that the transaction completed successfully, but that the transaction object throws the error while notifying clients that it has completed. That is, from the .NET Framework's point of view, the notification is post facto, not part of the transaction, and so errors during the notification do not cause the transaction to roll back (because it has already completed). Unfortunately, because in this case the notification is being picked up inside LightSpeed, it's not obvious to an external client like your application code that the error is occurring at the notification (post-committal) stage rather than the committal stage. At this stage the best I can suggest is handling the exception and checking for ObjectDisposedException vs. DbException or other possible committal failures. Even then, you will need to start a new unit of work because the exception prevents us from performing our post-commit actions. I'll chase up Jeremy to see if he has any further info or better ideas. I've also noticed that in many cases we don't actually need to perform any post-commit actions. I'll see if we can add a check to bypass the error-prone framework call if there are no actions to perform. Are you using L2 caching or full-text search? If not we can probably work around this for you. |
|
|
Hi Ivan, Thanks for the feedback. I am not sure what you mean by L2 caching, but we are certainly not using full-text search. I find it strange that this only seems to occur on some machines, and not others. I would welcome any additional sugestions you may have. Thanks |
|
|
By L2 caching I mean the additional, cross-unit of work caching you get with the CachedAttribute (or the designer Cached setting): http://www.mindscape.co.nz/blog/index.php/2009/11/05/whats-the-deal-with-lightspeed-caching/ This needs post-commit handling so that the shared cache is updated only when the changes are committed to the database. (Similarly full text search is interested because it wants to update its shared index only on a successful commit.) I've committed a candidate fix so that we only check for transaction committal if there is anything we actually care about. This should bypass the framework error if you are not using L2 caching. Please understand that we believe this to be a workaround for a .NET Framework bug and we may not be able to address the underlying cause if you subsequently need to implement L2 caching or full-text search. If it turns out that you are using L2 caching (and from a previous support query I have a vague memory you might be -- but I may be mixing you up with someone else -- it is Friday evening here *grin*), let me know and I'll see if I can wedge something in so that at least you can distinguish a doubtful cache issue from a failed save issue. Otherwise, the candidate fix will be in the 28 August nightly build and I hope it will resolve the immediate problem. |
|
|
Thanks for the feedback, didn't know anything L2 cache, but now I do, I can think of severl places it would be useful for lookup data etc. However, that being said, it is not something I am going to implement in th near future. Also, the transactions I am trying to perform here, woul definately never be L2 cached, and would always be fetched fresh. I will get the nightly build tomorrow and hope it resolve the issue. As usual, many thanks for your help. |
|