NetTalk Central

Author Topic: Multiple users, multiple file sets  (Read 4966 times)

rjolda

  • Sr. Member
  • ****
  • Posts: 321
    • View Profile
    • Email
Multiple users, multiple file sets
« on: March 30, 2009, 03:01:29 AM »
Hi,
I am trying to understand on a high level, how the Net talk sever operates.
I would like to have different user groups log onto different directories with their respective data.
I can Set the path with the login by the company name.
I am trying to understand how the server handles each file request.
Does the server keep the files open ?
Are they open on a thread for each session?
Are they open and closed for each request?
DO I need to store the fully qualified file name in a session variable and send it with each request?
TIA,
Ron Jolda

bshields

  • Sr. Member
  • ****
  • Posts: 392
    • View Profile
    • Inhabit
    • Email
Re: Multiple users, multiple file sets
« Reply #1 on: March 30, 2009, 05:55:46 AM »
Hi Ron,

This is a question i put to Bruce at the Australian Dev Con in 2007. With his and Geoff Thomsons' assistance I got it working.

What I wanted was separate customers being able to log into a single version of my nettalk app, however they opened up their own separate copy of their data, rather than a consolidated database with CustomerID segment prefix everywhere.

I got it working using Postgres and FM3. In summary, at the WebServerHandler function prior to anything happening I would resolve which customer was on the given request and set all the database filenames appropriately. So that when NetTalk opens the file it is the file in question.

Its all heavily threaded, so files are opened for each thread and closed. So this approach is possible.

Regards
Bill

rjolda

  • Sr. Member
  • ****
  • Posts: 321
    • View Profile
    • Email
Re: Multiple users, multiple file sets
« Reply #2 on: March 30, 2009, 11:58:43 AM »
OK,
I follow you so far.
At the web handler level, do you query the Global queue based on the session ID and then set the path appropriately for each request - this assumes that the file is opened and closed with each thread.  Is this the correct thought process?
Thanks,
R Jolda

bshields

  • Sr. Member
  • ****
  • Posts: 392
    • View Profile
    • Inhabit
    • Email
Re: Multiple users, multiple file sets
« Reply #3 on: March 30, 2009, 10:17:29 PM »
Exactly.

I pass the identifier which indicates which database to use on the URL, So i use GetValue not GSV. But that should also work.

Bill



Bruce

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 11244
    • View Profile
Re: Multiple users, multiple file sets
« Reply #4 on: March 31, 2009, 01:51:45 AM »
Hi Ron,

Good questions!

>> I can Set the path with the login by the company name.

yes, step 1 is to match the user to a data set. The most obvious way of doing this is via the login.

>> I am trying to understand how the server handles each file request.
>> Does the server keep the files open ?

no.

>> Are they opened on a thread for each session?

no.

>> Are they open and closed for each request?

yes. (conditionally of course - ie it doesn't open _all_ the files, only the ones which are needed.)

>> DO I need to store the fully qualified file name in a session variable and send it with each request?

no. what you do, in the WebHandler, in the ProcessLink method, BEFORE the parent call, is set ALL your file path names. You don't open the file or anything, just set the name.
Of course the variable you use for full path names MUST (I repeat MUST) be threaded.

Then when (if) the file is opened later on, the full path name is set.

Incidentally, you should set it from a SessionQueue variable, ideally not a GetValue setting. If you are passing in some stuff via the URL, then ideall use StoreValue to store this in the SessionQueue, before then using the SessionQueue variable when setting the file's path.

ie
  self.StoreValue('dataset')
  customersfilename = p_web.GSV('dataset')

This works better for those (possibly dynamic ajax) requests where the dataset is not passed. In that case the user gets their "most recently used" dataset.

Cheers
Bruce

Rob Mikkelsen

  • Full Member
  • ***
  • Posts: 107
    • Yahoo Instant Messenger - flashpott
    • View Profile
    • Email
Re: Multiple users, multiple file sets
« Reply #5 on: April 03, 2009, 01:02:17 PM »
Bruce, Bill and Ron,

Great discussion! 

To extrapolate a little, I make great use of the in-memory driver to reduce the disk reads since I am currently running 23 sites on one server (and growing - I don't know what the limit will be).  So, in addition to the above, all that would be required to have the best of both worlds is one additional field to isolate each site in the table.  I have approximately 60 tables, but only a dozen or so are not moved to memory at startup so this may be a very efficient way to handle multiple sites.  Since my URLs all contain the site name, the database is easy to determine.

This may be well worth pursuing.  Thanks for the insight!

Two questions (or at least one compound one):  Will consolidating all the sites into one server with dynamic file paths a) slow the delivery of data considerably, or b) free enough memory or system resources that it would be worth the time and effort to implement?

The downside, of course, is that if I have to shut down one site to adjust site adaptation I will have to bring them all down.

Rob

Bruce

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 11244
    • View Profile
Re: Multiple users, multiple file sets
« Reply #6 on: April 03, 2009, 11:26:23 PM »
>> Two questions (or at least one compound one):  Will consolidating all the sites into one server with dynamic file paths a) slow the delivery of data considerably,

I wouldn't think so. The server is multi-threaded, and C6 that's preemptive, so there shouldn't be much of a difference between multiple processes and multiple threads. But I don't have any data to support this, only a hunch.

>>  free enough memory or system resources that it would be worth the time and effort to implement?

I don't think it'd free any resources other than RAM. CPU and disk would be consumed the same regardless of the approach.

It will be a LOT easier to maintain I would think - and a lot easier to add new sites to a server. Although to replace the program all sites would be off.

cheers
Bruce