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.
thanks and okay - one more reason for XData.
XData is doing this all automatically?
In each request XData provides you with a TXDataOperationContext object with several helper data there, including a thread-safe Manager instance, a connection pool, and the request/response objects: http://www.tmssoftware.biz/business/xdata/doc/web/txdataoperationcontext.htm
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)?
yes, by using custom code. You can send session id in a custom header and check the request for example and process the authorization.
Ok. But I do not understand from the documentation where I can intercept a call into the xdata server.
Thanks for your support.
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.
Hi. Thanks a lot for your support.
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. :-)
Good. Yes, username/password adds Basic authentication to the server
Hi Wagner - I have a followup on this thread - since the question belongs now to XData I post there in a second.