Currently, I trying Vaadin 8 + Spring Boot. and enable spring session store into Redis.
However, for simple view works, but when introducing some other databean or some component, the “NoSerializable” error will start showing everytime.
For example:
Add Vaadin-SpreadSheet will cause NoSerializable error, due to apache POI is not serializable.
SpringData-MyBatis Dao will also cause the same error.
…
So, my question is
why Vaadin need to store all this instance into session?
Is there any walkaround to slove this error completely instead of using “transient” ?
because for “autowired” reference, can use “transient”, but for some UI Component like “Spreadsheet”, which looks like impossible.
Vaadin Framework is by design holding the UI state in the JVM memory. This is why it can provide it’s poweful programming style.
Most Vaadin apps don’t ever serialize session. You’ll need that only if you want to have perfect high availablity setup, but otherwise it is usually most efficient and easiest for developers to have sessions in memory only (and sticky sessions in clustering).
If you really need to share sessions among with your server nodes, you’ll have to pay attention to serialisation as you have realised. Same as with all server centric UI frameworks. If Spreadsheet component don’t support serialisation, you could probably add a bug report. I don’t know exactly how it works, but it might be possible to fix it.
If Vaadin need to hold all UI status in JVM memory, is any way to minimize the memory usage or cache without serialization?
Because currently, looks like vaadin session required large memory compare to other framework like spring MVC.
In stateful architectures you get easier development model, productivity and better performing applicaiton in certain cases, but at the expense of memory usage. The memory usage should though be quite small, depending a bit how you build your application.
If you use spreadsheet, you probably can’t get rid of the fact that it loads all that content to the memory, but with Grid and select components, you can often use lazy loading, so that you don’t need to refer all options from your UI (~session). I’d first profile the app, see how much it uses memory and see if it is a problem. Most often it is cheaper just to buy a hosting solution with more memory, than to really look into optimization. Then see if you can do some thing for the parts that consume most memory (you most often can) and if that don’t help your most probably have a huge amount of users (“google scale”) so it might actually be better to choose a stateless architecture and spend more money on the actual development.