Closed lee-alexander closed 7 years ago
gabikliot
commented
8 years ago Unless you need a strong isolation between clients for security, there is no need to use silo per client. Using client ID as part of grain ID is the better approach.
No problem with your own persistence layer. A lot of Orleans users use their own persistence layer, as it gives them more flexibility.
veikkoeeva
commented
8 years ago @lee-alexander Indeed, currently your choice to is to differentiate betweeen connection string (either to a different database or something like APP_NAME) or by ID. I don't think getting a hold of the silo instantiated providers is currently possible, but if it were, you could then use something like CONTEXT_INFO or other means to achieve this. The provider has internally a few interceptors that are used to pick (de)serializer, deciding whether to stream or not etc. This is the new provider that is in 1.3.0.
And indeed, as @gabikliot pointed out, it's a perfectly valid option to use application specific logic. The new provider that comes in 1.3.0 tries to be an efficient "blob storage" where on can pick between binary, JSON and XML serialization and accordingly a slot in the DB and also storage-side processing is supported. There is more in the documentation, in the SQL Server script itself and then some more design-time rationale at https://github.com/dotnet/orleans/pull/1682#r71064076.
lee-alexander
commented
7 years ago Thanks for the feedback everyone. We ended up building infrastructure to transparently attach and remove the databaseID to the grain identifier, which has been working well so far.
sergeybykov
commented
7 years ago @lee-alexander Can you share what you are solving with Orleans? Is it at the point that it could be added to http://dotnet.github.io/orleans/Community/Who-Is-Using-Orleans.html?
We currently evaluating Orleans as a way to supplement our existing 3-tier web architecture to improve throughput and reduce the need for always reading from the database by taking advantage of in-memory grain state.
A brief overview of our existing 3-tier SOA architecture:
Each service has an in-memory cache for immutable or rarely-changed data, but given that much of our data is very mutable this has limited use and is local to that particular instance of the service.
We would like to introduce Orleans in between our existing services and the database. However, the main question we need to answer is, how can we make sure each grain knows the appropriate database to talk to? In our existing services, this is accomplished through the current session information passed along with the request. Some ideas we've thought of:
We wanted to ask the community for thoughts and to see what the recommended approach might be, as we are still new to Orleans. Thanks!
One quick edit: We will likely not use the built in persistence functionality, instead opting for something like Entity Framework / raw SQL to work with our large existing DB schemas.