Automatically start PersistenceService

[GoogleCodeExporter]

Having to write an "initializer" class for even the most trivial
persistence needs is something we can avoid. Maybe provide an API, or start
it automatically.

What I've done for the current Hibernate support in the trunk is I create
the SessionFactory lazily. So _or_ the user calls
PersistenceService.start() which loads the SessionFactory, _or_ we start
the SessionFactory the first time it is accessed. That might be good
enough. Any comments?

Original issue reported on code.google.com by robbie.v...@gmail.com on 22 Aug 2008 at 12:17

[GoogleCodeExporter]

Not thrilled, but definitely acknowledge the problem of people forgetting to 
call start(). That's warp-persist's 
number #1 complaint, easily.

So I will concede the lazy init. Let's do that if we can using DCL or some 
performant method. Good call Robbie.

Original comment by dha...@gmail.com on 22 Aug 2008 at 12:38

[GoogleCodeExporter]

Implemented for Hibernate
The LifecycleSessionFilter will also help.

Original comment by robbie.v...@gmail.com on 23 Aug 2008 at 3:22

• Changed state: Started

[GoogleCodeExporter]

Currently implemented:
- We load PersistenceServices lazily. Calling start will force a load 
immediately.
- Added LifecycleSessionFilter, which is a SessionFilter that starts/stops the
PersistenceService. Technically this filter could even make sense for
UnitOfWork.TRANSACTION, it'll just have no WorkManagers. Should we enable that?

Original comment by robbie.v...@gmail.com on 9 Sep 2008 at 10:02

[GoogleCodeExporter]

Well if you're using UnitOfWork.TRANSACTION then the filter doesn't make sense 
since the unit of work will 
already be started/ended.

Let's keep it throwing an error unless UOW is REQUEST.

Also wondering if there might be a clearer name for the two filters--Managed 
and Unmanaged - SessionFilter?

Original comment by dha...@gmail.com on 9 Sep 2008 at 11:46

[GoogleCodeExporter]

What I meant was that people may still like the automated starting/stopping, 
even 
when no WorkManagers have been registered (which is what happens in 
UnitOfWork.TRANSACTION). So you could register the filter just to have that. 
You 
could even map it to some URL you will never use to avoid the overhead of the 
"no-op" 
filter. I acknowledge that it's bit ugly, but still it could be useful to get 
things 
going.

I don't mind a rename, but if we go for that proposal I would do SessionFilter 
and 
ManagedSessionFilter (so no unmanaged..)

Original comment by robbie.v...@gmail.com on 10 Sep 2008 at 12:43

[GoogleCodeExporter]

We now throw an exception when no WorkManagers have been registered. It's hard 
to
check on UnitOfWork because of the multiple modules support we have now. 
WorkManagers
do not get registered in UnitOfWork.TRANSACTION so this should be enough.

Also renamed LifecycleSessionFilter to PersistenceServiceSessionFilter. We do 
not
support it with UnitOfWork.TRANSACTION because it is not consistent with
SessionFilter. But we should consider that use case (automated start/stop) so 
I'll
create a new issue for it. Maybe we should multibind all the PersistenceService
instances.

Original comment by robbie.v...@gmail.com on 21 Dec 2008 at 3:18

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by robbie.v...@gmail.com on 22 Dec 2008 at 2:28

• Added labels: Milestone-Release2.0

[GoogleCodeExporter]

Can we just call it SessionFilter and do away with the non-lifecycle version? 
People can override init() and 
destroy() if for some crazy reason they dont want the lifecycle managed for 
them.

Original comment by dha...@gmail.com on 23 Dec 2008 at 5:35

[GoogleCodeExporter]

Maybe we can then provide an init-param that they can set? Like 
managePersistenceServices=false. Overriding is always more tricky because you 
need to 
remember not to call super.init() and what not (most IDE's generate code that 
does).

Original comment by robbie.v...@gmail.com on 23 Dec 2008 at 12:05

[GoogleCodeExporter]

Done (with init-param). I named it PersistenceFilter.

Original comment by robbie.v...@gmail.com on 23 Dec 2008 at 5:20

[GoogleCodeExporter]

I don't like init params, too spring-like =(

I don't see any problem with just letting them figure it out. It's not a major 
use case where people DONT want 
lifecycle. Moreover, they can do it by composition, etc. There are many paths 
for hackers we don't need to 
support them.

Original comment by dha...@gmail.com on 24 Dec 2008 at 12:19