Re: Optimising cache performance

2003-03-08 Thread gphat
 What implications does this have on the size of the cache that can be
 created with IPC::MM

I believe that documentation is telling you that each OS governs the 
amount of shared memory you can have in different ways.  Linux, for 
example, has a variable called shmmax, accessible 
as /proc/sys/kernel/shmmax, which controls how much shared memory you 
are allowed to allocate.  I think Solaris' setting lives in /etc/system 
somewhere.

Cory 'G' Watson
http://gcdb.spleck.net





Re: Enforcing user logged in from only 1 browser?

2002-04-15 Thread gphat

 It's #5 that's troublesome.  I wasn't sure how I could expire the older 
 session (since the session key that matters is sitting client side).  I 
 guess I could keep a table of invalidated session keys, and check 
 against that every time in along with all the other checks going on in 
 authen_ses_key().  I was just mainly asking if there was an existing 
 solution out there.

I'm not sure I follow your session id problem.  When I check a session, I ask 
the client for it's ID, then look the session up by ID.  To 'expire' the 
session, I simply delete it from the session store (File or Postgres).

Cory 'G'
Watson





Re: Enforcing user logged in from only 1 browser?

2002-04-12 Thread gphat

How are you handling your sessions?  I use Apache::Session::Postgres.

In my scenario, if I needed to do this, I would check the list of valid 
sessions I have for one that exists for the user.  ie, if 'gphat' tries to 
login, I check to see if any of the sessions the db are for user gphat.  If so, 
eliminate it and create a new one.

Using an Apache::Session might not be the answer, as you'd have to check each 
active session.  Depending on the situation, that might not be acceptable.

You could roll your own session handling, it's not that hard.  Then add a 
username field to the session table, so you can index and search by it.

 Hello all,
 
 I'm looking for a straightforward approach to extend our AuthCookie 
 sessioning to enforce that a user is only logged in from one browser at 
 a time.  For us, it would suffice that if the user tries to log in from 
 a 2nd browser, the first session would just be expired.
 
 I was thinking that upon login I could save the AuthCookie key in that 
 user's db entry as current_session_key and I could blank it out when 
 they explicitly log out.  Then during login, I would be able to see if 
 there's another key still out there for them.  The tricky part for me is 
 figuring out if that key is still an -active- session as opposed to 
 having just left their browser open last night or something.  And also, 
 if I do determine that it is another active one, how would I expire it?
 
 Anyone done this type of thing previously?
 
 Thanks,
 Fran