I have been trying to resolve a somewhat intermittent issue working with a long running state machine running inside a WorkflowApplication. I can step through the workflow and this behaves as expected, transitioning through the states as expected, then a bookmark is reached which then persists the workflow. However, the workflow is then aborted and I get the following message:
The execution of an InstancePersistenceCommand was interrupted because the instance owner registration for owner ID 'ba26f4e9-f38b-4179-aa09-31ab9f8af337' has become invalid. This error indicates that the in-memory copy of all instances locked by this owner have become stale and should be discarded, along with the InstanceHandles. Typically, this error is best handled by restarting the host.
The Sql Instance store is initialised as follows:
SqlStore = new SqlWorkflowInstanceStore(ConfigurationManager.ConnectionStrings["SqlInstanceStore"].ConnectionString);
SqlStore.HostLockRenewalPeriod = TimeSpan.FromSeconds(15);
SqlStore.InstanceCompletionAction = InstanceCompletionAction.DeleteAll;
handle = SqlStore.CreateInstanceHandle();
InstanceView sqlView = SqlStore.Execute(handle, new CreateWorkflowOwnerCommand(), TimeSpan.FromSeconds(30));
SqlStore.DefaultInstanceOwner = sqlView.InstanceOwner;
WorkflowHost = new WorkflowApplication(WorkflowDefinition, inputs);
WorkflowHost.Run();
To create the bookmark:
context.CreateBookmark(bkmk, OnResume);
The exception doesn't really provide enough information to help troubleshooting this issue. Any help would be appreciated.
I managed to resolve this by using an overload of the instance store where I am now passing a new GUID. Need to understand this a bit more.
handle = SqlStore.CreateInstanceHandle(Guid.NewGuid());
Related
I have ASP.Net 4.7.2 window service which is processing NServiceBus messages. Currently it is deployed to On-Premise server. It has retry mechanism as well and working fine. Now I am going to containerizing it. While running into docker window container, it is doing SQL operation using Entity framework and giving exception as mentioned below:
The configured execution strategy 'SqlRetryingExecutionStrategy' does not support user-initiated transactions. Use the execution strategy returned by 'DbContext.Database.CreateExecutionStrategy()' to execute all the operations in the transaction as a retriable unit.
While running locally by installing manually or on On-Premise server, it is working fine but in container it is throwing exception.
Can any one help me what can be the root cause?
It sounds like the piece of code does manual transaction management and is not wrapped within an execution strategy execute.
if your code initiates a transaction using BeginTransaction() you are defining your own group of operations that need to be treated as a unit, and everything inside the transaction would need to be played back shall a failure occur.
The solution is to manually invoke the execution strategy with a delegate representing everything that needs to be executed. If a transient failure occurs, the execution strategy will invoke the delegate again.
https://learn.microsoft.com/en-us/ef/core/miscellaneous/connection-resiliency#execution-strategies-and-transactions
using var db = new SomeContext();
var strategy = db.Database.CreateExecutionStrategy();
strategy.Execute(
() =>
{
using var context = new SomeContext();
using var transaction = context.Database.BeginTransaction();
context.SaveChanges();
transaction.Commit();
});
``
We are using the SQLite.NET PCL in a Xamarin application.
When putting the database under pressure by doing inserts into multiple tables we are seeing BUSY exceptions being thrown.
Can anyone explain what the difference is between BUSY and LOCKED? And what causes the database to be BUSY?
Our code uses a single connection to the database created using the following code:
var connectionString = new SQLiteConnectionString(GetDefaultConnectionString(),
_databaseConfiguration.StoreTimeAsTicks);
var connectionWithLock = new SQLiteConnectionWithLock(new SQLitePlatformAndroid(), connectionString);
return new SQLiteAsyncConnection (() => { return connectionWithLock; });
So our problem turned out to be that although we had ensured within the class we'd written that it only created a single connection to the database we hadn't ensured that this class was a singleton, therefore we were still creating multiple connections to the database. Once we ensured it was a singleton then the busy errors stopped
What I've take from this is:
Locked means you have multiple threads trying to access the database, the code is inherently not thread safe.
Busy means you have a thread waiting on another thread to complete, your code is thread safe but you are seeing contention in using the database.
...current operation cannot proceed because the required resources are locked...
I am assuming that you are using async-style inserts and are on different threads and thus an insert is timing out waiting for the lock of a different insert to complete. You can use synchronous inserts to avoid this condition. I personally avoid this, when needed, by creating a FIFO queue and consuming that queue synchronously on a dedicated thread. You could also handle the condition by retrying your transaction X number of times before letting the Exception ripple up.
SQLiteBusyException is a special exception that is thrown whenever SQLite returns SQLITE_BUSY or SQLITE_IOERR_BLOCKED error code. These codes mean that the current operation cannot proceed because the required resources are locked.
When a timeout is set via SQLiteConnection.setBusyTimeout(long), SQLite will attempt to get the lock during the specified timeout before returning this error.
Ref: http://www.sqlite.org/lockingv3.html
Ref: http://sqlite.org/capi3ref.html#sqlite3_busy_timeout
I have applied the following solution which works in my case(mobile app).
Use sqlitepclraw.bundle_green nugget package with SqlitePCL.
Try to use the single connection throughout the app.
After creating the SQLiteConnection.
Apply busytime out using following call.
var connection = new SQLiteConnection(databasePath: path);
SQLite3.BusyTimeout(connection.Handle, 5000); // 5000 millisecond.
I encounter a fatal crush of an asp.net application when i run the app the second time. The first time after a re-build runs successfully, but the second run (without a new rebuild) fails. After a new re-build the app runs again but the second run without a new rebuild fails etc. So i have to rebuild each time for an app run to be successful.
Error: Cannot resolve type [BiFiModelSweden.BiFiModelSwedenClass] for object with name 'BiFiModelSweden' defined in file [C:...\bin\BiFiContext.xml] line 8
This occurs at the last command below while creating the IApplicationContext which is null:
String cx1 = ConfigurationManager.AppSettings["cx1"];
String cx2 = ConfigurationManager.AppSettings["cx2"];
IApplicationContext cxt = new XmlApplicationContext(HttpContext.Current.Request. MapPath(cx1), HttpContext.Current.Request.MapPath(cx2));
After profiling the development webserver running the application, using ANTS memory profiler, we get an output:
Not all objects were deleted from the contextregistry. Did you forget to use base.Dispose()?
We've then tried all we can to use the dispose method using all sorts of ways. We cannot get to overcome this fatal crash of the application!
extra observation: log4net keeps logging even if the application is stopped mid-way. Does this symbolise a zombie session? could this be the problem, that we never kill one session completely when we start a new applicaiton run/session? leading to the fatal exception? that the previous session is left hanging and holding on (locking) to resources?
if this is the case, we've tried all ways of killing the session:
* session.Abandon()
* gc.finalize()
* etc
nothing works. The only workaround is manual deletion of the cache...which is impractical. How do we solve this!!
After doing some refactoring to my WF4 service, I got this exception when calling some of the operations:
The execution of the InstancePersistenceCommand named {urn:schemas-microsoft-com:System.Activities.Persistence/command}LoadWorkflowByInstanceKey was interrupted by an error.
My xamlx file contains a few receive/sendreplytoreceive pairs, as shown below. The exception sometimes happens on receive2, sometimes receive3.
receive1 (no correlation, cancreateinstance=true)
send reply to receive (initializes content correlation on generated ID)
receive2 (correlates on ID, cancreateinstance=false)
send reply to receive
receive 3 (correlates on ID, cancreateinstance=false)
send reply to receive
After doing a lot of debugging and making sure all correlations where set up right, the exception disappeared for new instances of the workflow.
What does the exception mean, and why did it show up and why did it dissappear all of a sudden? Is it a code/xamlx issue or something with the infrastructure (AppFabric/SQL)?
I'm hosting the WF service with IIS/AppFabric, using AppFabric' SQL persistence.
According to this support note this error can be the result of a race condition between the Receive and a Delay activity expiring. Is this possible in your workflow.
I kinda figured mine out... aparently if you point your persistance store in a SQL previous to 2012 you get the error... so all i had to do is put mine persistance store in a SQL 2012...
When I had this problem it turned out to be a mistake in my connection string when instantiating the persistence store object.
SqlWorkflowInstanceStore store = new SqlWorkflowInstanceStore(connStr);
I realise this an old question but fixing the connection string got rid of my error while running store.Execute() so I thought I'd share!
I have WebService that is hosted by ASP.NET web site. Inside the TransactionScope object is used to handle transactions:
using (TransactionScope scope = new TransactionScope())
{
...
scope.Complete();
}
The problem is that during debugging, when I am going through each line in step-by-step mode,
transaction timeout is occurred and any attempt to access DB crashed with '' error, and as a result: further debugging is prohibited.
How could I handle that without deleting mentioned lines of code?
P.S. I've tried to find, how to increase a time-out of created transaction, but didn't find something helpful.
Any thoughts are welcome.
Thanks.
You can specify an infinite timeout for the Transaction by passing in a zero length TimeSpan as part of the constructor:
using (TransactionScope scope = new TransactionScope(TransactionScopeOption.Required, new TimeSpan(0)))
The TransactionScopeOption of Required is what is used as default with your parameterless constructor.
See http://msdn.microsoft.com/en-us/library/ms172152(VS.90).aspx for more information.