[rt-devel] Problem with Session management with SetupSessionCookie

[Ross Williamson]

Hey all (firstly sorry for the subscribe msg sent to the list teach me
to to fully read instructions)
(Might be the wrong list but im proposing to write the patch to fix this
problem as well so im looking for advice)

I have com across an interesting problem recently with
SetupSessionCookie using mysql.

I have other virtual hosts on the same apache instance all using
Apache::Session::MySQL to stop their session data.  Now they all use the
database.sessions type convention when I create the Apache::Session::XX
object.

That makes sure that they don't write their session data to other
places.  In particular they all write to the same database within mysql,
so I can do optimisations on just that db without effecting other db's.

So to recap 3 other mod_perl/DBIx::SearchBuilder/Apache::Session virtual
hosts alongside RT.
The 3 other sessions write to a table sessions.sesssions in its own db
nicely optimised.

(note I don't have Apache::DBI loaded either for this) 
For some reason im finding the following behaviour... If I quickly and
continuously reload the web page from one of my other sites (to ensure
that every apache instance has the db handle loaded and pointing at a
diff db) and then try to load RT I get "cannot write to session
OTHERDB.session"

Now I don't have a session table in OTHERDB (since all mine use the same
DB.TABLE for their session data).  As a test turning off mysql session
storage (and using files) proves that that is where the problem is.  And
more so the problem is non repeatable when just using normal RT
functions (ie they must select the right DB.TABLE format, or im just
lucky)

So there are 2 questions
1) Was RT only ever expected to run on its own apache/mod_perl instance?
(therefore this is a design constraint)
2) Has anyone else seen this behaviour?

The only way to fix this (based on my reading of Apache::Session
documentation) is to fully specify the tie rather than just giving the
$RT::Handle->dbh to it (which assumes the handle will always be pointing
in the right place)

Hopefully someone can recognise the scenario and help me out before I
start hacking.

Cheers

Ross


--
Ross Williamson - Director 
Mobile : +44 7876308 566
Email  : ross.williamson at abilisk.com
------------------------------------------------------------------
This message may contain confidential and/or privileged information. If
you 
are not the addressee or authorized to receive this for the addressee,
you 
must not use, copy, disclose or take any action based on this message or

any information herein.  If you have received this message in error,
please 
advise the sender immediately by reply e-mail and delete this 
message.  Thank you for your cooperation.