mlwmohawk wrote:
On Friday 21 December 2001 10:45 pm, Yasuo Ohgaki wrote:
I was thinking about a PostgreSQL session manager. How is that going to
work? IMHO PostgreSQL (currently) is completely wrong for such a task.
I'm well aware of the issue you mentioned :)
PostgreSQL has one real behavior problem. Updates act as if you do a
delete then an insert, i.e. for transactional isolation, an updated row
is added new, and the old one is marked as deleted. Sessions are all
about updates, and any really active server cluster will expose
PostgreSQL's worst behavior.
I agree. It will slows down thing a *LOT*.
But it's faster than files save handler with proper
administration, I suppose.
I actually doubt it it will be. An insert into a database like PostgreSQL has a lot more overhead than just the basic file manipulation.
After any serious usage, you will need to vacuum the table. In 7.1, that
will lock the table and render the system unusable for a few minutes.
When 7.2 is released, vacuum will not lock the table, but you have to
have it running on a constant basis.
That's true. Users! you *MUST* run vacuum! As we mentioned, db like
session will slow things down a *lot* without vacuum!
Yea, at my company we currently use Oracle for session management. I will be trying to use msession as time goes on, but there is so much code to change.
Oddly enough, it is because of PostgreSQL's limitations that I resurrected some code I was working on for beowulf clusters, for msession.
The problem of coherent data and syncronization in a beowulf cluster and a web farm are almost identical.
:)
The only thing I can think of is using the large object interface, and
storing the unstructured PHP session data as a large object. It may not
be as fast as regular SQL, but that may eliminate the update problem.
I have to check current implementaion of text/bytea type.
It may be as efficient as large object now. (I think it is, isn't it?)
Thanks for pointing it out. :) I might add your suggestion to
my ToDo list.
The reason I suggest the large object interface is that I think you can update the unstructured PHP session data string into a large object without causing the row to be updated by PostgreSQL.
This could cut down a lot of row updates, and performance may not degenerate as fast.
Thanks.
I'll check about it.
BTW, users must vacuume constant basis still! Even I make use
of large object.
The benefit of using pgsql session save handler is users can
add more fields to session record as user needs.
User can use standard I/F (i.e. SQL) I think some people
will like it, even if it is not as fast as msession ;)
msession is pretty good, but it is not a SQL database. I totally understand your objective. I was going to write a PostgreSQL based session manager, but I came to the conclusion that PG isn't ready for it yet. I would love to be proven wrong. I think PostgreSQL is great.
One more interesting msession twist, after coming to the conclusion that PG wouldn't work, I wrote a set of functions for PostgreSQL first. Then, as I was writing the session handler for PostgreSQL, I just figured I'd write it to talk to msession directly.
The API exists, in PostgreSQL, to join against msession data in an msession session.
That's great! I'll check your code!!
Besides, PostgreSQL limitations are really large,
it good for DoS attack or keeping session for a long time, too.
Believe me, I'm not trying to sell you on msession in any way. You are heading down a road I traveled about 6-8 months ago, and i'm ust trying to be helpful. If you need anything, including me to shut up, just let me know.
I know you're nice person :) (I really mean)
--
Yasuo Ohgaki
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com