mORMot Open Source

esi

Member

Registered: 2013-02-10

Posts: 14

Sample 20 questions

I'm seeking some clarifications on how it all hangs together using the approach illustrated in this sample:
1) Is the service object only created/destroyed once per the entire server lifetime, or are there cases when it's re-created?
2) I have noticed that the service calls are happening in different threads from call to call, is this guaranteed, or can threads be re-used, i.e.: is there a fixed pool of threads? This would also have implications on how I call things from these service methods.
3) There's apparently no built-in session support with this approach, is this correct? I don't want to go root/Auth for this, but I will need session support, so if I'm correct, I'll need to write my own session support, probably within the context of this service class if that's a single instance that exists for the entire process lifetime.
4) All methods return JSON in the same format with "result" packed as an array (while I only want to return 1 value here), plus an extra "id"=0 parameter - can I have more control over this format with this approach and what is this last "id" parameter? In fact, I'd probably prefer to just have the automatic {}'s around my values.

TIA, Alex.

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,272

Website

Re: Sample 20 questions

Most of your questions are already answered in the "interface based services" part of the SAD pdf document.
Please check the latest "unstable" (but preferred) 1.18 revision from http://synopse.info/files/pdf/Synopse%2 … 201.18.pdf

Short answers, from October 17th version:
1) See "17.4.3. Instances life time implementation"
2) Threads are the one from the HTTP server thread pool, in your case, I suppose - see also "Note also that all those life-time modes expect the method implementation code to be thread-safe and reintrant on the server side..." and following text page 277
3) root/Auth can be pretty light, e.g. when using the TSQLRestServerAuthenticationNone class - see "Authentication schemes"
If you want a cookie-based session, you will have to handle it at hand: you have access to the incoming request from the global ServiceContext threadvar - see "Accessing low-level execution context"
4) "id" is used for some kind of instance life time (this is e.g. the ID of the per-client, per-user, per-thread or per-group session).
See "Custom returned content" and TServiceCustomAnswer kind of method function result to have full hand at the returning data - note that if you want to have full access to the requests details, a method-based service is more direct.

esi

Member

Registered: 2013-02-10

Posts: 14

Re: Sample 20 questions

Thanks! Trying to digest this slowly ;-)

- sicClientDriven is probably precisely what I need ;-)
- Re-using the ID works, but it gives me a new random thread at every call. Is there any way to force the threads to be allocated to user-driven sessions? - I think this would make a lot of sense in this case.
- Now I'll need to figure out how to tell what session I'm running in from within my interface implementation.
- And then figure out how to control the timeout / explicit session termination.
- I do not seem to be able to provide a custom Create constructor to my class - it just never fires, unless I declare it as a "class constructor" and then some code inside it doesn't do anything, i.e.: logging would not log anything. It's not a big deal, though. But I could not yet confirm object creation/destruction pattern because of this.

I'll try to spend more time with this until I get something close to what I need...

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,272

Website

Re: Sample 20 questions

There is currently no way to force the threads to be allocated to user-driven sessions.
Only possible way is to execute the service in the main thread.
Could you please create a feature request in http://synopse.info/fossil/reportlist ?

You have all session-related information in the global ServiceContext threadvar - see "Accessing low-level execution context".

The session timeout parameter is retrieved from User.Group.SessionTimeout.

Did you try TInterfacedObjectWithCustomCreate? It is the purpose of this class to have a virtual constructor fired.

esi

Member

Registered: 2013-02-10

Posts: 14

Re: Sample 20 questions

Had the request created - 8307f8a547998a54d3e433ae5198079cddf382dd