Closed sunshine-attack closed 10 years ago
yes, AsyncDocumentSession
is not thread safe. You need a new instance of AsyncDocumentSession
for each request in a concurrent environment. This is not an AspNet.Identity.RavenDB implementation restriction, it's how RavenDB sessions work.
Isn't it a AspNet.Identity.RavenDB implementation restriction though? Because if the RavenUserStore
accepted a DocumentStore
and opened a new session itself on every call instead of accepting a singular session, this problem would go away.
It seems a bit cumbersome to have to instantiate a new ApplicationUserManger
multiple times in a single context. It appears contrary to how the default Entity implementation works and prevents AspNet.Identity.RavenDB
from being a drop-in replacement for the Entity implementation.
then you have another problem which is unit of work. RavenDB supports transactions and an identity library shouldn't be responsible creating your session.
I've never used the transaction feature of RavenDB, but I can appreciate that it is useful to have available. I see the design choice.
Thanks for explaining your design choice.
sure, happy to help. Thanks for bringing this up.
I'm running into concurrency issues using the 2.0.0x implementation. Depending on the the timing of each call to the UserManager, I receive the following error when trying to use more than 1 API call that incorporates the RavenDB session in a controller context:
My understanding is that the RavenDb
AsyncDocumentSession
only allows one async request at a time per instance of itself. This results in the above error being thrown, again depending on the timing, if more than one request is used per controller context.Is there a way to avoid this? Do I need to wire up a new
ApplicationUserManager
with a newAsyncDocumentSession
each time I make a API call toApplicationUserManager
?