Modify ↓
Ticket #63 (closed enhancement: fixed)
Opened 8 years ago
Last modified 8 years ago
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: | |||
| Release Notes: | |||
| API Changes: | |||
Description
To handle "preferences", personal time zone settings (#17) and add more 'intelligent' features, we need simple session handling.
Attachments
Change History
comment:1 Changed 8 years ago by jonas
- Milestone set to 1.0
- Severity changed from critical to enhancement
- Version changed from 2.0 to 0.1
comment:2 Changed 8 years ago by daniel
- Version changed from 0.1 to Trunk
comment:3 Changed 8 years ago by daniel
- Version changed from Trunk to devel
comment:4 Changed 8 years ago by rocky
comment:5 Changed 8 years ago by daniel
- Milestone changed from 1.0 to 0.8
comment:6 Changed 8 years ago by daniel
- Owner changed from jonas to daniel
- Status changed from new to assigned
I've started working some on this now.
comment:7 Changed 8 years ago by daniel
- Keywords session added
comment:8 Changed 8 years ago by daniel
- Resolution set to fixed
- Status changed from assigned to closed
Implemented in [617].
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.