I have an uncertainty how I need to deal with possible concurrent access to a datamodule which I use within a service that is running a sparkle server.
Do I need to implement a lock or something similar to prevent concurrent access to the datamodule or should I create an instance of the datamodule for every request and implement a connection pool?
What would be best practice - if concurrency is not dealt with anyhow by something between htp.sys and the sparkle server?
If you are using just Sparkle (not XData/RemoteDB), you should handle concurrency yourself. Each Sparkle request is processed in a thread so you might have two or more requests being processed at the same time. You must know if what you are accessing is thread-safe or not. If you are using a database connection, best option would be using a connection pool indeed.
Ok - great. Will I also be able to deal with security via this context (eg. disallow to query all entities of a specific type - but only those associated with a specific session id)?
Ok. But I do not understand from the documentation where I can intercept a call into the xdata server.
E.g. if http://server:2001/tms/xdata/Customer is requested ... where would I put my custom code to prohibit that the clients request would get fulfilled?
Well, since you mentioned Sparkle, I thought you were considering using XData service operations, which are more flexible and allow you to implement any server-side code, even non-database related.
If you want to intercept the standard XData rest operations, there is are undocumented (because it's subject to change) virtual methods in TXDataServerModule that you can override to add custom code to the standard request handlers. For example, there are methods OnEntityRetrieve and OnEntitySetRetrieve that you can override and throw a 403 exception if user is not authorized.
Yes - I want to use XData service operations - but I do not want to provide the users the whole entity rest acces provided by XData. setting a username and password would also prohibit a client to access the service methods without the username password - correct?
So it seems this OnEntity* requesthandler info was excatly the information I needed. :-)