Affects Version/s: 11.1
Previous Issue Keys:LSNBLDR-722
This is a low-level change to how the database is handled. There's no real way you can test to see if it does what it's supposed to, but you can check to make sure it doesn't break anything.
Create a new item of every type. Just go down the add menu and add one of each.
Then edit each object to make sure that changes show.
In principle group access control should be set for each item type as well.This is a low-level change to how the database is handled. There's no real way you can test to see if it does what it's supposed to, but you can check to make sure it doesn't break anything. Create a new item of every type. Just go down the add menu and add one of each. Then edit each object to make sure that changes show. In principle group access control should be set for each item type as well.
We are having an issue that is only affecting our live instance where
when you are in a Lessons page and select to add some new text to the
page you enter some words and click "Save", the item always gets added
to the page, but sometimes the text contents you entered are lost, so
you end up with an empty item in the page. We can't reproduce this on
dev or test machines although did see it on a staging machine when it
was running slowly. You can then edit the item and add the text and
this always correctly updates the item (can't get this to fail).
Looking at the code it seems the transaction boundary is on all the
calls between SimplePageBean and SimplePageToolDao so any call across
this boundary will get a new transaction and possibly a new hibernate
sessions. When a new item is added to the page there appear to be 3
calls across this boundary:
- The first one is a call to a saveItem() which adds the new row, but
it doesn't yet have all it's properties set. We know this must be
completing as we see this much in the DB.
- The second one is a call to update() which is done when setting the
groups on the item.
- The third one is another call to update() which is called at the end
which is redundant if there are groups.
In between the first and second calls the HTML description is set on
the object so that is hinting that everything after the first one
isn't working when we see a failure. My current guess is that on a
heavily loaded server we end up getting back a different
session/transaction after the first call and this is what causes it to
fail. Although from looking at the code any errors that result of
hibernate not managing to persist something should result in an error
showing up in the UI and we're not getting any in the UI or in the
Our hibernate sessions should be bound to threads but once the
transactions has been closed, I'm not sure if you will get the same
session back the next time.