Hi, I don't if it is your problem but, in Uniface 9.5, we had do write this code to have persistent attributes.

lvList = $item("SESSIONATTRIBUTES", $webinfo("WEBSERVERCONTEXT"))
putitem/id lvList, "MYATTRIBUTE", a_value
putitem/id $webinfo("SESSIONCOMMANDS"), "SetAttributes", lvList
putitem/id $webinfo("WEBSERVERCONTEXT"), "SESSIONATTRIBUTES", lvList ; If we don't to this, attributes are lost

In 9.6, if we do that, errors HTTP500 were generated. For avoiding theses errors, we write this following code

putitem/id lvList, "MYATTRIBUTE", a_value
putitem/id $webinfo("SESSIONCOMMANDS"), "SetAttributes", lvListe

which follows more the Uniface documentation

It's not that much data, only a 5 or 6 attributes with small string values. I'll make some tests and if the error appears again i'll try storing the session data on the DB

6 small attributes shouldn't be causing a problem. Let us know what you find, maybe something more than just the size causing issues.

So everything seems to be working. Just out of curiosity if i want to store de session data on the DB, how can i manage that data for example when the session is closed by the user, like when the browser is closed?

Glad to hear it's working. Fundamentally there's nothing you can do to catch the "end" of every session. It would be good practice to clear up the session after a user clicks logout, but beyond that I wouldn't attempt to catch every way a user can leave your application. As an extreme case, there is no way to catch a user who pulls the network cable out of the back of their PC! Instead, you need to decide how you want to clean things up. One way would be to run a batch job that deletes sessions that haven't been accessed for a certain amount of time, perhaps matching Tomcat's session time-out setting.

Hi, There are a number of ways to store session state in your web application. The best way depends on the exact application, however, a good start might be to look at the session commands that Uniface provides out of the box. For an overview give the help topic "Session Management for Web Applications" a read. Basically this makes use of the session cookie that Tomcat sends out to the browser to identify users across requests. You can store information against the session by doing something like this, for example, when a user logs in: putitem/id $webinfo("SESSIONCOMMANDS"), "ChangeSession", "NEW" putitem/id $webinfo("SESSIONCOMMANDS"), "SetAttributes", "UserName=%%pUserName%%%·;UserId=%%pUserId%%%" This will create a new session for the user (to avoid session fixation) before storing the user name and user ID in session state. On subsequent requests we can re-retrieve this information like this: vSessionAttributes = $item("SESSIONATTRIBUTES", $webinfo("webservercontext")) vUserId = $item("UserId", vSessionAttributes) Regards, James

Hi James,   Thanks for the info

Hi, What's the max length of the SESSIONATTRIBUTES? I've encountered an HTTP 500 error setting some extra attributes. I fixed the error deleting an attribute before adding the new ones. 

I can't see any limits stated in the Uniface documentation (not to say there aren't any somewhere). The 500 error would imply something is happening at the Tomcat level. Tomcat doesn't seem to impose any limits itself, but it's possibly simply causing Java to run out of memory. How much data are you actually trying to push into SESSIONATTRIBUTES? If it's a lot then you might want to consider storing the bulk of the state data in a database table keyed on the session ID, which you can get using the SESSION topic from $webinfo("WEBSERVERCONTEXT"). This is the same session ID that's sent out to the browser but we can just grab it and use it how we want. When defining what's "a lot" of session data, bear in mind that Tomcat will be storing data for every user of your application. So it multiplies up quite quickly.