I'm trying to switch a process I have that works with lots of data from a standard Session to a StatelessSession, and I'm wondering why the decision was made to not allow proxy loads. Basically my process does something like 40,000 inserts and maybe 2 updates. I don't really need to keep all that in a standard session, but reworking the process to not use any proxies is, to say the least, a daunting task.

Is there some very bad reason why loading items through the proxies is a bad idea when not stored in the session cache? I'm just trying to understand the design decision more thoroughly. Any insight as to why it works the way it does would be appreciated.

Thanks in advance.

There is no reason for using a StatelessSession which has lots of limitations.

This is the best way to do batch processing with JPA and Hibernate.

No, that's what I've been doing for years, but it's incredibly slow and error-prone. There is no reason to maintain a persistence context that I throw away. In my persistence context my process probably grabs and maintains some 500,000+ records over time of which, only about 30-200 are needed across the entire process.

Using a stateless session is ideal from a raw performance standpoint. I need to insert all 80,000 records in a single transaction, and I need to be able to maintain certain reference objects that all 80,000 items refer to. Flushing and clearing the persistence context adds extra overhead, and leads to issues where some things are cleared prematurely. Having to reload those items into the cache after every flush/clear is where most of my errors have come from over the years.

StatelessSession was designed not to work with the st-level cache.



So, no 1st-level cache, no Proxies. You'd either reconsider your design choices or stick to it and see for yourself if that was a good idea or not. ;)

Yes, I read the very limited documentation on stateless sessions before going this route. I'm not worried about aliasing or other cache-missing issues as I'm not updating anything that could possibly be aliased. It doesn't explain WHY the proxies don't work.

Do the proxies rely on the other caches? Would they work without the caches, but it was decided not to support them to prevent aliasing? I'm looks for DESIGN decisions regarding this choice, not Javadoc copy-pasting.

There's enough documentation about StatelessSession, considering its limited usage.

I'm now improving the User Guide, especially for interesting stuff like what's the purpose of every annotation. Unfortunately, StatelessSession is not on my agenda, so, if you want more, just send us a Pull Request, and I'll integrate it.



When you access a lazy Proxy association, this is how the association gets initialized. See the session parameter? That's why you can't have Proxies for StatelessSession.



So, why would it need the Session, right?







Makes sense, right? If you are eager to learn more about it, here's the Hibernate package on GitHub.

Thanks for that info. I had seen that documentation, but couldn't find the bytecode classes that are used.

for the latest Master (6.0?) here: https://github.com/hibernate/hibernate- ... eptor.java

I'm not seeing any reason why a StatelessSession can't be passed to the proxy loader. It's using the SharedSessionContractImpl for the session parameter.

Does this mean that proxy loading could be available to StatelessSessions in a later release?

In git terms, that's called Latest commit 87e3f0f on Apr 19, 2016.



No, it won't be added in a future release. If you use StatelessSession a lot, then you are better off using jOOQ instead.

No, I wouldn't be using them a lot. My main use for the stateless session is this bulk loading operation which is a small but intensive part of a very large application. 99+% of the application would still use the standard session management. Switching to jOOQ would be a much larger rewrite than I want to tackle.

It would be nice to not have to refactor so much code though to work around stateless proxy loading issues and to somewhat seamlessly switch between the backing sessions. But then as noted in the docs, with the aliasing, if some tree structure was aliased a lot in session, it could lead to a lot of memory usage that could be mitigated by pre-loading it in bulk as forced to do now without the proxy support.


If the proxy classes support it, why not? Overall, I feel it should be supported with LARGE caveats that it could (but not always) cause lots of extra database traffic due to aliasing instead of loading them manually, but I think for users who have (apparently) fringe cases like mine, it would be a large time saver for development.

Thanks.

Why do you think you need to use either Hibernate or jOOQ. You can easily combine them so that you use Hibernate for write operations, and jOOQ for advanced SQL queries and bulk processing (e.g. MERGE, UPSERT, MySQL batch inserts with IDENTITY column).



If you think it's possible, send us a Pull Request, and let's then discuss its actual impact.

At the moment all my business logic is linking to my DAOs rather statically. In theory it should not be a problem, but on a large code base over 12 years old, it could lead to a lot of refactoring in order to support 2 different data layers between jOOQ and Hibernate/QueryDSL that I use now.

For my codebase, it would probably be easier for me to add a second set of QueryDSL generated classes that used direct SQL instead of hibernate as the backend.



Thanks, and duly noted. I may consider doing that, but at the moment I don't have the expertise in the hibernate codebase to do that quickly. If I have some downtime, I'll look into it.

If you use QueryDSL already, no need for jOOQ. Use QueryDSL for all those use cases when you now use a StatelessSession.