System.Transactions.Transaction class has TransactionCompleted event to which I can subscribe.
Is it possible to schedule a continuation after IDbContextTransaction.Commit is called?
Sure, I may call code explicitly after committing a transaction, but I have an overloaded version of SaveChanges where I want to detect externally started transaction and add some actions to run after it was committed.
Related
I'm trying to understand how the partitions are executing the events when there is retry policy in place for the event hub and I can't find an answer to what happens to new events when one got an error and is retrying in the same partition in the event hub?
I'm guessing that the one that got an error shouldn't block new ones from executing and when it reties it should be put at the end of the partition, so any other events that got in the partition after that event got an error should be executed in order without any blockage.
Can someone explain what is actually happening in a scenario like that?
Thanks.
It's difficult to answer precisely without some understanding of the application context. The below assumes the current generation of the Azure SDK for .NET, though conceptually the answer will be similar for others.
Retries during publishing are performed within the client, which treats each publishing operation an independent and isolated. When your application calls SendAsync, the client will attempt to publish them and will apply its retry policy in the scope of that call. When the SendAsync call completes, you'll have a deterministic answer of whether the call succeeded or failed.
If the SendAsync call throws, the retry policy has already been applied and either the exception was fatal or all retries were exhausted. The operation is complete and the client is no longer trying to publish those events.
If your application makes a single SendAsync call then, in the majority of cases, it will understand the outcome of the publishing operation and the order of events is preserved. If your application is calling SendAsync concurrently, then it is possible that events will arrive out of order - either due to network latency or retries.
While the majority of the time, the outcome of a call is fully deterministic, some corner cases do exist. For example, if the SendAsync call encounters a timeout, it is ambiguous whether or not the service received the events. The client will retry, which may produce duplicates. If your application sees a TimeoutException surface, then it cannot be sure whether or not the events were successfully published.
I'm using a custom Jersey ExceptionMapper to map my unchecked exceptions into error responses (as described in the documentation). My problem is that the transaction is not rolled back, every DB modification made before the exception is persisted.
The same thing happens if, instead of using the ExceptionMapper, I throw a WebApplicationException.
How can I send an error response to the client preserving the normal behavior (rollback the transaction)?
I found a similar question here, but I don't use spring.
What you can do is use a RequestEventListener to manage the transaction throughout the lifetime of the request. You can listen for RequestEvent.Types, which includes events such as RESOURCE_METHOD_START, ON_EXCEPTION, RESOURCE_METHOD_FINISH, etc. You can begin the transaction at the beginning of the request processing and commit or rollback the transaction depending on if it a successful processing or an exception is thrown.
This is pretty much what Dropwizard does with it's #UnitOfWork. You can see how it is all implemented in this package. Look at the UnitOfWorkApplicationEventListener. You'll see how they implement what I was talking about above.
Operations that occur during model initialization don't end up in the undo history, so what is the purpose of Model.beginCreationCompoundOperation, as opposed to Model.beginCompoundOperation? My best guess is that it used internally to wrap the initialization function call into a compound operation and was not meant to be public.
Documentation of method
Your guess is correct - beginCreationCompoundOperation is used to wrap the initialization function call so that we know that the changes made were used to create the initial document state, which (among other things) can't be undone.
This function was not meant to be public. Calling it during model initialization will fail immediately, and if it is called after model initialization the changes will refuse to commit on the server and you will need to reload (a creation compound operation can only be applied once - this is what prevents the creation from occurring multiple times if you create a document and then immediately load it on multiple machines).
This function will be removed in a future update to the Realtime API.
We have a situation in which, at some point in our code, we are seeing certain objects as detached, but we don't explicitly detach the objects ourselves. What SQLAlchemy methods/actions can cause objects to become detached? Maybe closing a session or something similar?
Note: I've read the SQLAlchemy documentation, which does cover re-attaching objects to sessions, but is relatively more scant on what actually can detach instances implicitly.
session.close() will detach all objects. A rollback as noted will detach those objects that were INSERTed in the rolled-back transaction as well.
I guess the main one would be if you were to "rollback" a session. As the docs say:
Objects which were initially in the pending state when they were added
to the Session within the lifespan of the transaction are expunged,
corresponding to their INSERT statement being rolled back. The state
of their attributes remains unchanged.
How I can implement rollback transaction in wp7. Presently my issue is after insertion or deletion I am calling submits changes, In that time if i made a tombstone the app exits. how I can handle this situation I am planning to use try catch and if any exception caught means I need to rollback the changes. Please anyone help me to implement the same in wp7.
Why do you need to rollback when the application becomes tombstoned? Technically your application is not aware of when it is tombstoned, you are only aware of when it becomes de-activated. See the following lifecycle diagram:
(The image above is from the blog post http://www.scottlogic.co.uk/blog/colin/2011/10/a-windows-phone-7-1-mango-mvvm-tombstoning-example/ which describes the lifecycle in detail)
Whenever you application is de-activated, you can handle the Deactivated event. From MSDN:
Applications are given 10 seconds to complete the Deactivated handler
This gives you the oppurtunity to cleanup, save state and perform other activities before your application becomes de-activated.
I presume you are commiting your transaction when your application state changes? Does the commit run on the UI thread? i.e. is it blocking? If so, you do not need to do anything else (other than ensure it does not take more than 10 seconds). If your commit is running on a background thread, you will have to ensure that your Deactivated event handler blocks until the commit is complete.