1

I actually solved this already but I find the solution to be weird so say the least. If found that I was getting the oh so nice

"ERROR: request not found in the TrackedRequests. We might be creating and closing webs on different threads"

Which would be very familiar to most SharePoint developers. In this case it is for a workflow. I managed to solve it but it was a tad puzzling for me. After doing some trial and error, this apparently solved it.

Previous Code :

SPWeb = workflowPriperties.Site.RootWeb;

Current Code :

Guid siteId = workflowProperties.Site.ID;

using (SPSite site = new SPSite(siteId))
{
  using (SPWeb web = site.OpenWeb(site.RootWeb.ID))
  {
    //Do Something
  }
}

This has solved the issues that were coming from my particular method. Although now I got an error message that now does not seem to come from my own custom code(I still have no idea why), I am puzzled as I was under the impression the workflowProperties object which was created as seen below :

public Microsoft.SharePoint.Workflow.SPWorkflowActivationProperties workflowProperties = new Microsoft.SharePoint.Workflow.SPWorkflowActivationProperties();

are all akin to getting them from SPContext which means they do not have to be disposed or closed. Does this mean that some properties of the SPWorkflowActivationProperties object are actually new instances of SPRequest objects or are derived from new SPRequest objects?

I hope my question does not seem overly dumb and if it this has been asked before. Please graciously point me to the thread that answers this.

Thanks.

Benjamin Wong
  • 599
  • 1
  • 8
  • 21

1 Answers1

0

Okay, I am not about the workflow properties issue but however I tracked down the error.

The issue was because of this code

public void readusersFromItems(SPListItem item)
{
 Guid siteid = item.Web.Site.ID;
 Guid webId = item.ParentList.ParentWeb.ID;

Taking getting the Guid based on the SPListItem objects from workflow properties and passing it into a library class seems to cause that problem whereby a Site and Web object is instantiated before giving you the ID. That behavior is just my guess because when I passed in Guid directly into the method, it solved the problem.

The takeaway would be to always pass in SPWeb and SPSite Guid into methods outside the workflow in library classes as deriving them from SPListItem objects WILL cause errors that are hard to trace.

Benjamin Wong
  • 599
  • 1
  • 8
  • 21