Well, I'm not sure if it's a 'memory LEAK' that you'd get, but I know what you mean.
Yeah, in this case you'll want to close the session. I would say, the usually, you'd want to have longer transactions. You've got a very fine grained transaction here, and if there are multiple databse hits, you'd be using ALOT of resources needlessly.
If it's an academic example to figure out how things work, it's good. If it's in an application, you'd probably want the transaction to be alot longer in duration, or at least, demarcated outsilde of the method.
Thank you very much, Cameron. Do you mean that I'll get a "memory FLOOD?"
I have a manager class that does quite a few of these small units of work. Would you recommend getting a session in the manager's constructor, and using it throughout?
In any case, I think I read somewhere that session.getTransaction().commit() does the work and then closes the session. Is that correct? If so, why do I still need to close it? And how exactly would I do it?
Yup! You're killing your application by doing the create/begin/commit stuff over and over again. That type of stuff tends to be the biggest performance problem in these apps - just too many Sessions and transactions created when just one would suffice.
There are lots of design patterns and best practices out there to guide you on these types of travels.