2) Since the role is just something hosted in a local VM under IIS, you'll run into problems with R's global state being shared in the VM that is spun up. If you have a couple of work items queued, setting mfrow, creating a variable in the global environment, or something similar will be available to the requests that come in after that first work item. Also, if the VM spins down, you lose any saved state, so independent requests that might assume that the backend state is preserved, could break. That was an issue for my use case. Also, if the R process throws an abort() or access violation, that VM is hosed and you don't really have a clean way of detecting it (executing various R functions is something I'm doing with my version).
What I've done is created a WCF IPC layer that push's the R process out of the IIS host and as such, allows for dynamic per-user or per-session R instances so that the user's state is preserved in a live session, but everyone is isolated from one another. I also have some "malfunction" tracking that allows me to start a new instance for the user if the previous one is hosed.
Good luck.
Blue Skies,
Ritch
What I've done is created a WCF IPC layer that push's the R process out of the IIS host and as such, allows for dynamic per-user or per-session R instances so that the user's state is preserved in a live session, but everyone is isolated from one another. I also have some "malfunction" tracking that allows me to start a new instance for the user if the previous one is hosed.
Good luck.
Blue Skies,
Ritch