Incomplete Commit

[Mike_Duncan]

Is there a way to schedule a process to commit  batches that go into the Incomplete Commit Queue?

[#2]

Marcus, I read your solution in another post and almost went that route. However I was able to resolve this by making sure that only a timer, to move documents to another queue, was in the initial queue. I had planned on moving to the classic workflow also, but just reworking the workflow queues seems to have done the trick.

I would suggest just making one change at a time. Moving to classic could cause some workflows not to work correctly.

Greg

[Marcus_Christi6]

as long as that worked for you great.  The problem is that if Core has timed out, the Thick Client itself doing the commit TO the initial queue cannot do so because it can't get a session ID; it never gets added to initial (if a user were doing an import, for example, they would get an error that says "document not added to workflow".  This is an indicator of a lost session ID and is the same that's happening to the service) thus it never gets handed off to the Timer Service Administrator service (our workflows are configured in this fashion and I still experienced the issue).  I observed the behavior many times before I narrowed it down to the Core/Classic setting.

Since the Thick Client does not have a Core session heartbeat, it will time out, guaranteed.  It's just a matter of when - which in our case was during critical production hours, unacceptably.

Additionally, as long as you have the handoff you described, it doesn't matter if your processing workstation is set to Classic for the purposes of document import.  It doesn't affect any other workstation that may need to use Core workflow.  The real fix is to give a way to override that timeout for the Thick Client, but I seriously doubt Hyland will write such an option into the Thick Client at this stage.

[Mike_Duncan]

Some do and some don't, no real consistency

[Mike_Duncan]

Manual committing

[#6]

One other thing I found was the way we were doing our database failovers. We are on MS SQL server 2008 R2, using mirroring. We also do not use the standard SQL port. What we found was that IIS did not always respect the ODBC connects using a different port number. There is a setting in the registry on the web/app servers that still point to the default SQL port. I changed that setting to point to the port number we use and our failovers now work without issue. I made the same changes on the servers that run the commit processes. I made these changes the same time as the workflow changes. I don't know if this effected the incomplete commit process or not. I suspect it did.

Just something else to consider.