Win a copy of Practical SVG this week in the HTML/CSS/JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Session Manager already configured for MultiRow but still receiving a session database write error

 
Tom Hinz
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here's the specific output in the error logs:

[5/20/09 9:02:20:717 CDT] 00000427 SessionContex E SESN0055E: BackedHashtable:handlePropertyHits - An attempt was made to write more than 2M to large column. The session data may be too large for the database column. Either put less data in the session or consider configuring Session Manager for MultiRow database mode.
[5/20/09 9:02:20:743 CDT] 00000427 SessionContex I BackedHashtableMR.handlePropertyHits this property is too big: FilterFormKey

Working with RAD 7.0, WebSphere 6.1 server, Struts.

After talking with the web admins and the server admins, I have determined that the session database is already configured for MultiRow. Our admins gave me (and the other programmers) the idea that we should never receive this error, and that the JVM will split the session automatically, and the size of the individual attributes do not matter.

Here's a sample list of the session attributes and their sizes
UserSecurityBeanKey - 5k
FrameworkRequiredBeanKey - 106k
UserInfoBeanKey - 11k
InquiryFormKey - 27k
FilterFormKey- 6 MB

The reason that the FilterFormKey is so large is due to initial application design to reduce database calls and the result set of the inquiry form is stored in an ArrayList under the FilterFormBean. This was designed to allow the user to filter the information based on their inquiry without having to hit the database a second time.

I had actually come up with an idea that would break up the result set into multiple lists and store them individually in the session, but i was told this would not solve the problem by one of the admins.

I would appreciate any help that can be offered on this topic,

--Tom
 
Cameron Wallace McKenzie
author and cow tipper
Saloon Keeper
Posts: 4968
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm curious, but can you write this from you machine with a simple JDBC call, bypassing Hibernate altogether? I'd just want to confirm it was a Hibernate issue, and not at a lower layer.

DB admins have been know to give bad advice if it helps them avoid doing work. At least, that's been my experience with db admins.

-Cameron McKenzie
 
Tom Hinz
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm really not sure about hibernate. The admins say that it is an issue with the heap and its size limitations. And unfortunately, getting them to increase the heap is near impossible.

Right now, we have patched the issue by restricting the search criteria, but this is not really the best answer for the application. I am still open to any other possible solutions (if any exist).

--tom
 
Cameron Wallace McKenzie
author and cow tipper
Saloon Keeper
Posts: 4968
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
>>The admins say that it is an issue with the heap and its size limitations.

I think it has to do with radiowaves from Saturn being directed at my brain.

If the admins have a theory, have them test it. Or do your DB admins put everything directly into production without ever testing anything?

Sorry, I just hate it when someone points a finger of blame but has no substance to back it up. Have them test their theory. Otherwise, go back to the users and tell them the functionality can't be implemented because some db admin doesn't want to spend thirty seconds doing a heap size change on a test machine.

-Cameron McKenzie
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!