As far as what can be trimmed off the RegionFactory and Region contracts...
- Radim Vansa You had specifically mentioned RegionFactory#nextTimestamp and Region#nextTimestamp should go away. Could you explain why again? IIUC it had something to do with Session exposing #getTimestamp? #getTimestamp on Session has a very specific meaning, but one that I think matches for caching's needs as well. In fact Session gets its timestamp from RegionFactory, so little chicken and egg there So we can certainly remove passing it around in the cache SPI calls as method args. Perhaps that is all you meant? IMO we can also get rid of Region#nextTimestamp; RegionFactory#nextTimestamp is enough for Session's need.
- Is "timeout" really different for each Region? Or is that more RegionFactory-level info?
- Regarding Statistics, we do currently leverage #getSizeInMemory, #getElementCountInMemory, getElementCountOnDisk and #toMap. Moving forward however, I propose that we consider removing these methods. Yes they are useful from a statistics/metrics point of view, but (correct me if I am wrong) not necessarily meaningful for the underlying provider to answer.
On a related note... I'd like to reconsider the "start up" sequence for RegionFactory impls. Currently one of the supported ctor signatures are used and then we call #start taking even more start up config. I'd like to instead have RegionFactory implement org.hibernate.service.spi.Startable (and Stoppable) to leverage automatically starting and stopping it as part of the normal Service lifecycle handling. Between ctor and #start, the RegionFactory is given access to:
- config settings Map/Properties
- SessionFactoryOptions
I specifically wanted to ask about the second one. Do any of you actually use it? |