Re: Open source WO - offer

On Sep 4, 2006, at 9:33 AM, Bruce Fancher wrote:

>
> Yeah, the whole detached object thing seems to be one of the  
> dumbest things
> about Hibernate.  I understand the principle("POJOs dude!"), but in  
> practice
> it seems to cause nothing but trouble (see "Open Session in View") and
> doesn't really buy you very much.  I asked some people at work with  
> more
> experience with Hibernate than I have why the practice in Hibernate  
> is to
> open and close a session with each request, whereas with EOF you  
> just leave
> one or more EditingContexts open.  No one seemed to know.  Any ideas?

Just to expand, the benefit of POJO model objects is in the fact that  
they have no dependencies on the persistence framework(in this case  
Hibernate), which means any business logic can be easily tested with  
a Plain Old Unit Test in isolation without loading configuration  
files or connecting to a database, or any other complication. If you  
believe in test first development, this is a major advancement.  Its  
also good for re-usability and maintainability not having your  
business entity classes and business logic tied to a particular ORM  
solution.

In Hibernate, although single session per request is an option, you  
also have the ability to use long running Hibernate sessions  that  
are disconnected after each request. This is the recommended way to  
implement user transactions that span multiple requests. I find it  
hard myself to come up with a good reason why detaching/reattaching  
objects is a good option. One detail that comes to mind is that the  
Hibernate session keeps strong references to all objects associated  
with it. This is why you you typically don't have a login session  
scoped hibernate session the way there is typically a session scoped  
editing context. The reason you have to make sure the Hibernate  
session is either closed or at least disconnected after each request  
is so the JDBC connection is released. In EOF, you don't need to  
worry about this because there is for the most part, a single open  
database connection shared by all editing contexts across the entire  
application or at least each EOF stack. EOF(even with multithreading  
enabled) only allows a single thread to access the database at a  
time. This fact about EOF, is IMO, one of its major flaws along with  
all or nothing global caching and are among the reasons why we have  
abandoned WO/EOF for a WO/Hibernate/Spring solution. We didn't want  
or need to redo the front ends of all our applications written in WO.  
We have developed support that allows WOComponents to have a locally  
scoped hibernate session that are automatically bound/unbound(using  
the common ThreadLocal pattern), and connected/disconnected around  
the WO request phases.

> Forgot a few more things:
>
> * Cayenne stack supports running custom query classes, so you can  
> extend standard query behavior, or implement custom database  
> "commands".
> * Cross-VM cache synchronization is built in.
> * Caching query lists (EOF only offers caching individual objects)
> * Paginated queries (I believe this is available via Wonder?)
> * (3.0 only) Pluggable cache implementation. So you can have a  
> single external managed cache, such as OSCache, used for many  
> things, ORM being only one of them. This is great for CMS-like apps.
>
> Andrus

Speaking of caching. As I mentioned above, this was another place I  
found EOF to be flawed. Our experience wast that, EOF is great for  
read mostly applications or single instance applications that handle  
all database updates, or for applications without fresh data  
requirements. IMO, EOF applications get way too complicated, if this  
is not the case, for example if for whatever reason you have database  
updates happening outside of your app(legacy system) or because you  
have more than one instance of your app, or multiple apps  
manipulating the same data, or whatever... Anyway, its not long  
before you are forced into having to deal with getting fresh data,  
which ties up the single database channel provided by the EOF stack,  
forcing you to use multiple stacks, or add more application  
instances, which further exacerbates your stale data problems. There  
are the distributed notification frameworks(not part of EOF), but all  
that is useless for non EOF updates, and is still only a bandaid  
solution to the fact that EOF forces an all or nothing caching model  
on you. Caching turns out not to be good ALL the time. Hibernate  
offers granular caching, for example by entity, so I can configure it  
to cache only what makes sense to be cached.  I never did understand  
how it makes any sense attempting to keep all those object stores 
(EOObjectStoreCoordinator + all EOEditingContexts) consistent using  
notifications even within a single process let along across multiple  
processes. It makes for A LOT of message traffic and requires locking/ 
unlocking, adds race conditions(is there a notification on the way?),  
etc.. I sure, don't miss chasing down application deadlocks, whether  
they were EOF bugs or developer caused. It just seems so much simpler  
to begin a 'Unit of Work', fetch fresh data from the database minus 
(read mostly data which is cached), make changes, and save. No  
database bottlenecks, no locking/unlocking, etc.

Not that Hibernate is without flaws, but is definitely a capable ORM  
solution that does what it does well. I have a few complaints about  
Hibernate as well, but none that have cause us much grief. I'm not  
too familiar with Cayenne. We checked it out about a year ago, but  
thought it might be a little too much like EOF and at the time did  
not support POJO's which have been of substantial benefit. I'd be  
interested to here comments if Cayenne addresses some of these issues.

-lenny