Modify ↓
Opened 21 years ago
Closed 21 years ago
#63 closed enhancement (fixed)
Session/user variables and storage
Reported by: | daniel | Owned by: | daniel |
---|---|---|---|
Priority: | highest | Milestone: | 0.8 |
Component: | general | Version: | devel |
Severity: | normal | Keywords: | session |
Cc: | Branch: | ||
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
To handle "preferences", personal time zone settings (#17) and add more 'intelligent' features, we need simple session handling.
Attachments (0)
Change History (8)
comment:1 by , 21 years ago
Milestone: | → 1.0 |
---|---|
Severity: | critical → enhancement |
Version: | 2.0 → 0.1 |
comment:2 by , 21 years ago
Version: | 0.1 → Trunk |
---|
comment:3 by , 21 years ago
Version: | Trunk → devel |
---|
comment:4 by , 21 years ago
comment:5 by , 21 years ago
Milestone: | 1.0 → 0.8 |
---|
comment:6 by , 21 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
I've started working some on this now.
comment:7 by , 21 years ago
Keywords: | session added |
---|
Note:
See TracTickets
for help on using tickets.
Typical J2EE Approach to Session Management
Just a little bit of extra info, typically long-term preferences are stored only for authenticated users. In a specific db table (often the 'user' table).
J2EE uses a cookie with the special name, 'JSESSIONID', to reference a unique ID in the actively running JVM (the JVM never terminates unless through error or manual shutdown). It then uses a map of maps (or something similar… would be a dict of dicts in python) to map ID's to maps of information that needs to be easily accessible (current timezone, etc). This allows for fewer roundtrips to the db to locate what the current timezone needs to be, etc. In the case of high availabilty, J2EE servers often also store serialized versions of the sessions (map of map's) to the filesystem and/or db. That way if the application server ever crashes, it can resume the sessions upon server relaunch.
Course in the case of trac.cgi, the python interpreter only stays loaded long enough to complete the request, and then terminates. So it would be required to store the sessions on the filesystem or in the db. In the case of storing the sessions in the db, there's no real advantage to storing easily accessible data like the timezone in the session, as that info is already in the db in the users preference table or some such similar place. In this case, the sessions seem be useless.