Hi all,
We can use SessionStorage and LocalStorage to store data on the client.
https://docs.lansa.com/14/en/lansa017/i ... 1_0295.htm
Then what about on server side?
Is there any way to store data on sever side?
Background:
The customer is creating server module and trying to do publishing web service.
Their server is Windows server 2019.
In their server module, they use
- Setting files stored in the specified folder
- Tables on local SQL Server
They'd like to avoid these to be loaded every time, so they want data to be stored on server module like cache.
They also tried to specify other server module as Ancestor but they couldn't.
Any advice will be appreciated.
Thanks in advance,
Best regards, Yukiko Ikeo
Storing data on server side
Re: Storing data on server side
Hi Yukiko
Thinking out loud on this...
When you store data in SessionStorage or LocalStorage in the client side, the information is stored "in the browser"
The "in the browser" most likely are one or a few files in the temporary folder that the browser uses.
When a web page calls a server module, is a lweb_job job (or the equivalent w3_p1200 process in windows) that
performs what that server module wants to do, then, the lweb_job could be reused by another job or be replaced
in a renewal process handled by the web monitor, etc.
If that server module wants to access something, easier way is to get to the disk, from a text file in similar way
to the sessionstorage or localstorage, or from a table, etc. indexed by the session id. I guess that accessing a text
file if the information is small and simple will be faster than accessing the sql database, you can do that with
the LANSA built ins or maybe even faster with xprim_file or similar primitives available today.
If you have another process running continuously in that server (like a service) and your server module wants to communicate
with it, it could exchange messages somehow, and that other process could store things in memory while running as well.
But that somehow could be more complicated to implement, I think. something akin the snd_to_data_queue and receive
builtins, but no those as they keep the data queue in the disk.
Thinking out loud on this...
When you store data in SessionStorage or LocalStorage in the client side, the information is stored "in the browser"
The "in the browser" most likely are one or a few files in the temporary folder that the browser uses.
When a web page calls a server module, is a lweb_job job (or the equivalent w3_p1200 process in windows) that
performs what that server module wants to do, then, the lweb_job could be reused by another job or be replaced
in a renewal process handled by the web monitor, etc.
If that server module wants to access something, easier way is to get to the disk, from a text file in similar way
to the sessionstorage or localstorage, or from a table, etc. indexed by the session id. I guess that accessing a text
file if the information is small and simple will be faster than accessing the sql database, you can do that with
the LANSA built ins or maybe even faster with xprim_file or similar primitives available today.
If you have another process running continuously in that server (like a service) and your server module wants to communicate
with it, it could exchange messages somehow, and that other process could store things in memory while running as well.
But that somehow could be more complicated to implement, I think. something akin the snd_to_data_queue and receive
builtins, but no those as they keep the data queue in the disk.
Re: Storing data on server side
Hi Yukiko/Dino,
you could use PERSIST in the Server Module. PERSIST allows you to 'temporarily' save Lists or Fields on a 'Session' basis.
To use PERSIST, you must have done a StartSession and then the Server Routines will need to have Session(*Required) to get the data.
'under-the-covers', I believe that LANSA likely stores the PERSISTED fields/lists in a file and retreives that data when it sees that it is the same session.
https://docs.lansa.com/15/en/lansa015/D ... SIST_E.htm
you could use PERSIST in the Server Module. PERSIST allows you to 'temporarily' save Lists or Fields on a 'Session' basis.
To use PERSIST, you must have done a StartSession and then the Server Routines will need to have Session(*Required) to get the data.
'under-the-covers', I believe that LANSA likely stores the PERSISTED fields/lists in a file and retreives that data when it sees that it is the same session.
https://docs.lansa.com/15/en/lansa015/D ... SIST_E.htm
Code: Select all
Begin_Com Role(*EXTENDS #PRIM_SRVM) SessionIdentifier('Session_1')
* xDemoSessionServices - XDEMOSESS
* Sample Server Module to demonstrate session handling
* Default Session status for all webroutines is Active
* Session timeout will be set to 10 seconds. Default is 300 seconds
Define Field(#gUserID) Type(*CHAR) Length(40)
* Persistent session data variables restored everytime a Srvroutine is executed
* Available to all routines
Persist Fields(#gUserID)
* Signin routine. If the user id is valid, the session will be activated
Srvroutine Name(Signin)
Field_Map For(*INPUT) Field(#User)
Field_Map For(*OUTPUT) Field(#io$sts) Parameter_Name(Status)
#User := #User.UpperCase
If (#Com_owner.VerifyUser( #User ))
#Com_owner.StartSession Timeout(10)
#io$sts := "OK"
#gUserID := #User
Else
#io$sts := "ER"
Endif
Endroutine
Mthroutine Name(VerifyUser) Access(*PRIVATE)
Define_Map For(*INPUT) Class(#xDemoUnicode128) Name(#User)
Define_Map For(*RESULT) Class(#xDemoBoolean) Name(#Result)
#Result := (#User = "LANSA")
Endroutine
Srvroutine Name(TestSessionState) Session(*Required)
Field_Map For(*OUTPUT) Field(#io$sts) Parameter_Name(Status)
* #gUserID contains the #User that was signed in (in this case it will be "LANSA")
* we can use #gUserID without having to pass it to this routine...
#io$sts := "OK"
Endroutine
Srvroutine Name(Signoff) Session(*Required)
#Com_owner.EndSession
Endroutine
End_Com
-
Yukiko Ikeo
- Posts: 26
- Joined: Fri Jun 09, 2017 11:58 pm
Re: Storing data on server side
Hi Dino and Brendan
Thank you for your reply
I've passed these information to the customer.
At last they've decided to access the text file for each request.
Thank you for your help.
Best regards, Yukiko Ikeo
Thank you for your reply
I've passed these information to the customer.
At last they've decided to access the text file for each request.
Thank you for your help.
Best regards, Yukiko Ikeo