Accessing the SQLRest at server side

h.hasenack · 2013-03-22 10:09:11

Hi Arnaud

On the Server side i have a background thread (actually a timer) that has to poll for changed data in a volatile (:mem:) table.
(btw, this table is modified by both client and server - it's a data exchange container for simulation results, parameters and other data.)

The polling is initiated by the client when a 'simulation session' is started, and upon its creation, the polling object obtains a link to the 'active' sqlrest (on server side!) like this:

function TLCSSimulationDataOnRestServer.GetSQLRest: TSQLrest;
begin
  if FSQLRest=nil then
  begin
    if Assigned(ServiceContext.Factory) then
      FSQLRest:=ServiceContext.Factory.RestServer;
  end;
  Result:=FSQLRest;
  if Result=nil then
    raise ELCSSimulationDataFatal.CreateFmt('%s.GetSQLRest - Restserver not available',[ClassName]);
end;

But the problem is, that this REST server may be destroyed because the eg client dropped the connection, and this causes an nasty AV in my server. So what I need to find out is if the FSQLRest link is still valid. I do not see a 'OnDestroy' event handler or something alike that I can use to nillify my FSQLRest field.

Any ideas?

Hans

ab · 2013-03-22 10:28:40

Note that when used, a local copy or a PServiceRunningContext pointer should better be created, since accessing a threadvar has a non negligible performance cost.

You can either override TSQLRest.Destroy then reset the in-thread reference to your background thread, or just use FreeAndNil() with a global variable (not very beautiful).

I'm planning to add some KISS but sophisticated thread process, within the Event-Driven upcoming feature of mORMot.
It will include timer events, and will be integrated to the whole process.

h.hasenack · 2013-03-22 12:14:25

And how about creating a REST client at server side? I could use the DLL or windows messaging based variant to 'clone' the SQLRest coudlnt I

This way the simulation data object would have it's own rest client. SO ... I can I create a "clone" like that from the active restserver when my simulation data object is instantiated?

ab · 2013-03-22 14:04:49

I still does not understand how you may have a REST server shutdown.
"this REST server may be destroyed because the eg client dropped the connection" ????

Why not make the background thread created by the main REST server?

h.hasenack · 2013-03-22 14:39:24

Hi Arnaud

Actually the RESTServer instance at the server side might be dropped by the moromt fraework, for whatever reason.

Putting my simulation in a separate thread will make the sqlrest server unavailable through the ServiceCOntext (since its a threadvar) so, during initialization I take a pointer to the restserver because the initializeion of the simulation thread is accomplished in the restserver thread that us currently servicing a client.

But I already decided it makes more sense to make the simulation have it's own client access to the rest server, even though it is in the server executable. The simulation actually is a bit of a rest client itself since it reads and writes data from the "main" server. This allows the simulation to continue running even when the client dropped the SQLRest connection and the TSQLRest instance is removed by the mormot service manager (or whatever you call it).

Hans

ab · 2013-03-22 15:19:04

I still can't understand how the TSQLRestServer instance is removed/dropped...
"the server side might be dropped by the moromt fraework, for whatever reason" does not make sense to me.

h.hasenack · 2013-03-25 07:16:58

Hi Arnaud

From my understanding, the 'client' session on the server side (or client thread?) is dropped some time after the connection with the client is lost. From the simulation thread's view this SQLRest instance, that i obtained from the servicecontext when the simulation thred was started, 'disappears' suddenly.

On other words: I want the simulation to be able to continue even when the client has closed it's connection. Culd be that other client sessions (eg a real time measureing system, or other users) feed data in to my simulation thread as well. Therefore my conclusion is that the simulation is not "owned" (= being destroyed by) the client thread that started the simulation thread, but that it should be more like a reference counted object.

I hope get what I mean.

|Hans

ab · 2013-03-25 11:03:06

Please read the SAD pdf (in 1.18 latest unstable version), about session handling and RESTful authentication.

By default, the session is managed by the client.
There is an explicit disconnection when the client instance is destroyed.
Auto-drop after a TimeOut is only a safety feature, to release resources, but it is not the "common way".
The HTTP connection could even be re-created (from TCP/IP point of view, e.g. due to connection problems), but the same session will be re-used by the client, until the client application is closed.

What I do not understand is what is a simulation, and why the TSQLRestServer instance could be destroyed.
When a client is disconnected, the TSQLRestServer is still there.
IMHO it still does not make much sense to me, and I still does not understand how/why you use the ServiceContext threadvar as such.

h.hasenack · 2013-03-26 08:07:11

I have been rethinking this, and I believe I have come to a deep misunderstanding of what is going on inside the server. :s

Anyway, Sorry for bothering you with it, I'll invest some time to get a better understanding.

Hans

ab · 2013-03-26 08:23:50

Feel free to post some feedback if the documentation is not clear enough.

You certainly may not be the only one having a misunderstanding!

h.hasenack · 2013-03-26 14:39:25

I was completely confused by the XE3(?) issue of the threadvar as described in http://synopse.info/fossil/info/155b09dc1b

now I'm all back in the clear again. The Sky looks blue again

Thanks for the fix within 10 minutes!

mORMot Open Source

#1 2013-03-22 10:09:11

Accessing the SQLRest at server side

#2 2013-03-22 10:28:40

Re: Accessing the SQLRest at server side

#3 2013-03-22 12:14:25

Re: Accessing the SQLRest at server side

#4 2013-03-22 14:04:49

Re: Accessing the SQLRest at server side

#5 2013-03-22 14:39:24

Re: Accessing the SQLRest at server side

#6 2013-03-22 15:19:04

Re: Accessing the SQLRest at server side

#7 2013-03-25 07:16:58

Re: Accessing the SQLRest at server side

#8 2013-03-25 11:03:06

Re: Accessing the SQLRest at server side

#9 2013-03-26 08:07:11

Re: Accessing the SQLRest at server side

#10 2013-03-26 08:23:50

Re: Accessing the SQLRest at server side

#11 2013-03-26 14:39:25

Re: Accessing the SQLRest at server side

Board footer