I am completely re-writing the entire project, I have arrived at the front end and wish to do fine-grained session management. I have chosen to use System.currentTimeMillis() as a session key, going through some fancy logic to establish new/existing/none and have now seen HttpSessionBinding class being used. I already have:
which I could easily change to HashMap or TreeMap(no-dupes/no-nulls)and key HttpSessionBindingEvent objects in the Map by a static synchronized accessor after isNew() method returns true.
There will obviously be some accepted manner of obtaining a SessionID from the javax.servlet package, I am still working on that. I already have random-int generation built-in several layers deep for keying sessions. Trying to juggle what the server considers a session across what I already have will likely result in 'deadly-triangles'.
I wish to harmonize with server session logic. Interface HttpSessionBindingListener can be *easily* accomodated with a soft-landing in the preliminary concept code I already have.
"The differential equations that describe dynamic interactions of power generators are similar to that of the gravitational interplay among celestial bodies, which is chaotic in nature."
Originally posted by Nicholas Jordan: I wish to harmonize with server session logic. Interface HttpSessionBindingListener can be *easily* accomodated with a soft-landing in the preliminary concept code I already have.
I think it would be hard for anyone to give you advice without knowing what it is that you trying to do with your own session handling that can't be done with the session handling provided by the servlet spec.
I only need to know what they key the session on, what the intended use of the class is. If it is in the 'machinery', it would make a third base of session identification. If I 'get' the SessionBindingObject - and store it alongside other keys I already have working, I intend to see if my stored copy matches the key that the server is working off of and just skip off to a simple meaningful html feed if several verificatons do not match up.
IOW - look normal unless the client shows some patterns that I am expecting to see. Perhaps keep fifteen or twenty 'sessions' disentangled in a multi threaded senario is a reasonable description of what I have in mind.