add missing flushes

[TorstenKruse]

We had an issue with HbnContainer 1.1 with Hibernate4.
Updating and deleting always failed.
We found out, that the changes were not written to db and the following re-loading came to unsynchronized data between table, container and database.

Simple flush()es after the data changed statements solved the errors.

For detaols see here:
https://vaadin.com/forum/-/message_boards/view_message/2243680

[gpiercey]

Flushes should not be required if the transaction is committed properly. In fact too many flushes can impact the performance of Hibernate on a busy system so it is not really a recommended practice.

The only time I've seen this behavior in HbnContainer it was caused by the session-per-request pattern being implemented incorrectly, or not implemented at all.

Could you please set a breakpoint in the doFilter method of your SessionInterceptor class and run your application to verify for me that the method is being called? Specifically, I want to be sure that the active transaction is being committed properly when your session completes.

[TorstenKruse]

First of all: You're right, too many flushes will cause really bad performance. We noticed this while trying to solve the error. Sending a flush() after each SQL-call would be really bad. But it is required only after the insert / update / delete. And theese should not be so numerous.

I'm not a Hibernate expert, so maybe you can tell me what we are doing wrong and what to do, to get it running without the flushes. I'll try to explain our setup more in detail.

We use Vaadin 6, Hibernate 4, mySql 5, c3p0 Pool and com.mysql.jdbc.Driver.
The Hibernate Session Factory is configured as spring bean.
We use the org.springframework.orm.hibernate4.support.OpenSessionInViewFilter to open a session at request start and let it close at the end of the request.We can see that the OpenSessionInViewFilter is working via its DEBUG logging.

For our spring services we use @transactional, but to the HbnContainer we pass the plain sessionFactory.getCurrentSession() without any transaction.

The error in HbnContainer occurs e.g. when deleting an entity. As I understand, the frontend will send just a single request to the server for deleting the entity. This request will call removeItem of the table, which passes it further to the container. In the removeItem comes:

    Session session = sessionManager.getSession();
    Object id = session.load(entityType, (Serializable) itemId);

    sessionManager.getSession().delete(id);

    // HK added
    sessionManager.getSession().flush();

    clearInternalCache();
    fireItemSetChange();

There is the delete() directly followed by the refreshing of the complete container content.Without the flush() we added, this will result in an error. I don't really understand why, perhaps you know better. But at least I think at this point it does not matter, if there is a transaction or not, because all statements (DELETE and SELECTs) would be in the same without requiring a commit between.

So, what do you think now, is there an error in out setup? And can you explain why the flush() is needed for us?

Or shouldn't really HbnContainer use the flushes to work also with this setup?

[gpiercey]

GP:
Just updating this issue with the information that was posted to the Vaadin forums. I want to keep all the information here in one location...

Horst Krause
12/15/12 7:49 PM

I found this thread because I have a similar error. I use the HbnContainer and after deleting an item, I get the following exception twice. Does anybody know what to do?

15.12.2012 20:45:03 com.vaadin.Application terminalError
SCHWERWIEGEND: Terminal error:
java.lang.NullPointerException
at sun.reflect.GeneratedMethodAccessor92.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.hibernate.property.BasicPropertyAccessor$BasicGetter.get(BasicPropertyAccessor.java:164)
at org.hibernate.tuple.entity.AbstractEntityTuplizer.getPropertyValue(AbstractEntityTuplizer.java:627)
at org.hibernate.tuple.entity.AbstractEntityTuplizer.getPropertyValue(AbstractEntityTuplizer.java:645)
at org.hibernate.persister.entity.AbstractEntityPersister.getPropertyValue(AbstractEntityPersister.java:4481)
at com.vaadin.data.hbnutil.HbnContainer$EntityItem$EntityItemProperty.getValue(HbnContainer.java:304)
at com.vaadin.data.hbnutil.HbnContainer$EntityItem$EntityItemProperty.toString(HbnContainer.java:499)
at com.vaadin.ui.CustomTable.formatPropertyValue(CustomTable.java:3570)
at com.vaadin.ui.CustomTable.getPropertyValue(CustomTable.java:3522)
at com.vaadin.ui.CustomTable.getVisibleCellsNoCache(CustomTable.java:1922)
at com.vaadin.ui.CustomTable.refreshRenderedCells(CustomTable.java:1541)
at com.vaadin.ui.CustomTable.refreshRowCache(CustomTable.java:2254)
at com.vaadin.ui.CustomTable.containerItemSetChange(CustomTable.java:3956)
at com.vaadin.data.hbnutil.HbnContainer.fireItemSetChange(HbnContainer.java:1025)
at com.vaadin.data.hbnutil.HbnContainer.removeItem(HbnContainer.java:986)
at com.vaadin.ui.AbstractSelect.removeItem(AbstractSelect.java:851)
at com.vaadin.ui.CustomTable.removeItem(CustomTable.java:3726)
at de.cominto.epad.common.vaadin.ui.EntityTable.deleteEntity(EntityTable.java:184)
at de.cominto.epad.common.vaadin.ui.TableContextMenuHandler.handleAction(TableContextMenuHandler.java:76)
at com.vaadin.ui.CustomTable.changeVariables(CustomTable.java:2581)
at com.vaadin.terminal.gwt.server.AbstractCommunicationManager.changeVariables(AbstractCommunicationManager.java:1460)
at com.vaadin.terminal.gwt.server.AbstractCommunicationManager.handleVariableBurst(AbstractCommunicationManager.java:1404)
at com.vaadin.terminal.gwt.server.AbstractCommunicationManager.handleVariables(AbstractCommunicationManager.java:1329)
at com.vaadin.terminal.gwt.server.AbstractCommunicationManager.doHandleUidlRequest(AbstractCommunicationManager.java:761)
at com.vaadin.terminal.gwt.server.CommunicationManager.handleUidlRequest(CommunicationManager.java:323)
at com.vaadin.terminal.gwt.server.AbstractApplicationServlet.service(AbstractApplicationServlet.java:501)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.springframework.orm.hibernate4.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:119)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.__invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:470)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Thread.java:662)

Horst Krause
12/16/12 2:01 PM

After further investigating and even debugging into to core, I think the problem occurs, when an item is deleted form outside the table and its container.
In this case I can not manage to refresh the table without any error.

Controlling entity = getHbnContainer().getEntity(target);
if (isDeletionAllowed(entity)) {
((MyService)getService()).deleteEntity(entity);
//removeItem(target);
this.unselect(target);
this.recreateHbnContainer();
//this.refreshRowCache();
this.discard();
this.fireItemSetChange();
this.requestRepaint();
this.requestRepaintAll();
this.requestRepaintRequests();
this.resetPageBuffer();
this.refreshRenderedCells();

As you can see, after checking if deleting is allowed, I delete the entity through my service (because using the removeItem(target) also caused the error above (without deleting in db).
Know I can delete it, but I cannot manage to refresh the rows shown in the table without error.
The refreshRowCache() which looked most promising also caused the exception above.
All the other may do what the want - but at least they don't manage to refresh the view.
So after succesfull deletion, the deleted row is still shown in the table.

The recreateHbnContainer reloads the container of the table. This will show the right result (wow!), but in the log file there is an exception:

java.util.ConcurrentModificationException
at java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:761)
at java.util.LinkedList$ListItr.next(LinkedList.java:696)
at com.vaadin.ui.CustomTable.changeVariables(CustomTable.java:2580)

Does anybody know, how to force the table to update its view without any errors?

Thanks for any help,

Horst

Horst Krause
12/18/12 1:00 PM

Finally we managed to solve this issue. There error occured because of some strange hibernate session <-> db synchronising. We copied the underlying HbnContainer and added a session.flush() after each insert, update, delete and now it works really good and fast.