NetTalk Central

Author Topic: In-Memory Tables  (Read 3382 times)

broche

  • Sr. Member
  • ****
  • Posts: 336
    • View Profile
    • Email
In-Memory Tables
« on: May 18, 2015, 03:21:47 AM »
Hi All,

Just a general question.  In Bruce's book on Webserver vber 2 it says:

If you are using an In-Memory table, make sure you do not have the /THREADEDCONTENT file driver option on the file. You cannot separate the data by thread, it must be done using a SessionID field which you must add to your file structure. The SessionId property is declared as a String(255).

I assume this is a typed in variable, not the threaded option?
What is the system doing with the SessionID you declared in the file?  I have not been putting this in my file declarations.

Brian.
Brian

peterH

  • Sr. Member
  • ****
  • Posts: 413
    • View Profile
Re: In-Memory Tables
« Reply #1 on: May 18, 2015, 04:36:43 AM »

I removed my answer here since Bruce provided the right answer below (and I learned a thing or two ;) )

Peter
« Last Edit: May 18, 2015, 06:11:54 AM by peterH »

Bruce

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 11250
    • View Profile
Re: In-Memory Tables
« Reply #2 on: May 18, 2015, 05:44:50 AM »
It's worth pointing out that people are sometimes reading /THREADEDCONTENT as ,THREAD, but that's not the same thing.

a) The Memory Table itself is thread-safe, but you want the file to have the ,THREAD attribute so that each thread gets its own record Buffer. So in this respect it's like all your other tables - ,THREAD must be on.

b) /THREADEDCONTENT is unique to the memory driver. It allows every thread to contain a "different file" - so the DATA is not shared across threads. This is unique to the memory driver - in all other drivers the data is obviously "the same for all threads".
With NetTalk you _do not_ want to use this /THREADEDCONTENT switch.

c) given that all users are sharing the same EXE, the same TPS tables, and yes the same Memory tables - if you are storing user information in a temporary table (TPS or InMem) then you need some field to tell one user's information from another. In a netWeb app this is the "Session ID" which is a string (up to 255 chars long.) Remember you are responsible for removing any data in here when the session expires (you would add code to .NotifyDeleteSession in WebHandler.)

If it's not clear let's chat about it on Thursday during the webinar.

Cheers
Bruce

broche

  • Sr. Member
  • ****
  • Posts: 336
    • View Profile
    • Email
Re: In-Memory Tables
« Reply #3 on: May 19, 2015, 12:05:43 AM »
Thanks Bruce,
Glad I asked - All clear except the last bit for Webhandler - that bit would be nice Thursday. 
In fact I am fuzzy on threading in regards to code in the Client Side options.  I think I am doing this wrong (or not at all) and am getting a GPF as a result.  Nice topic would be threadsafe code in those areas or when to use a prcess instead.


Brian.
Brian

Bruce

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 11250
    • View Profile
Re: In-Memory Tables
« Reply #4 on: May 20, 2015, 01:34:41 AM »
>> All clear except the last bit for Webhandler -

check out User Group Webinar #23 around the 1:29 minute mark. I imagine that covers some of your questions.

>> In fact I am fuzzy on threading in regards to code in the Client Side options.

Assuming your tables are marked as THREAD, all the code in here is thread-safe.
(The only possible unsafe code would be if you are accessing the WebServer object itself, ie
p_web.RequestData.WebServer....
and I'm guessing you're not doing that.

>>  or when to use a prcess instead.

using or not using a process has zero to do with Thread Safety.

cheers
Bruce




 I think I am doing this wrong (or not at all) and am getting a GPF as a result.  Nice topic would be threadsafe code in those areas or when to use a prcess instead.