You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Dan Adams <da...@ifactory.com> on 2005/09/30 23:27:26 UTC

hivemind vs. tapestry

Okay, I've read a bit online about this (like Howard's post) and I don't
want to start a flame war or anything but I'm thinking about design and
need to make a decision before this project goes much further. 

I'm currently using spring and hibernate and using services for all my
hibernate code. Unfortunately, i found out I was using the
session-per-operation antipattern (i know i know i'm sorry) which led me
to think about how to implement session-per-request with detached
objects (or even session-per-user-session would be better i think if
thats really possible). So now I'm seriously wondering: is there an
advantage to using both spring and hivemind and if so what is it? Or
should I simply drop spring and using only hivemind services? I'm using
spring beans for most everything right now.  One thing to consider is
DI/IoC is the only thing I'm using spring for currently (i'm not using
the spring aop or transactions) so as far as my usage I'm not sure if
there is a big reason to stick with spring other than I like it.

But can some of you out there with more experience with
tapestry/hivemind/spring/etc give me a little insight? Thanks. :)

-- 
Dan Adams
Software Engineer
Interactive Factory


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org


RE: hivemind vs. tapestry

Posted by Patrick Casey <pa...@adelphia.net>.
	Dan,

	I won't comment on Hivemind because I'm still a fairly content
Tapestry 3.0.3 user and probably always will be (the transition to 4.0 looks
way too big to make with an existing project). I do, however, want to offer
some words of (hopefully at least) wisdom regarding
session-per-user-session.

	I was running that particular pattern in an app up until recently,
but I eventually tore it out. There were three major problems:

	1) The session gets *big* and I do mean *big* unless you're really
careful to evict everything you don't need and/or use temporary sessions for
all your non transactional data.
	2) Long session do *not* play nice with the hibernate L2 cache which
uses the session creation time to determine cache freshness. So if I create
a session now (12:00) and do a query at 1:00 with it, data put in cache at
12:30 is not considered fresh because the session's creation date < 12:30.
In practice this makes for a lot of cache misses.
	3) You don't have very granular control over your transactions. Want
to insert three audit records and update the user record, but roll back the
changes to the workorder because it failed validation? You're sort of SOL if
all three deltas exist within the same transaction.

	On the plus side, it did utterly solve all my lazy initialization
errors and through aggressive use of temp sessions I could solve (or at
least tmitigate) the session pollution issue, but the inefficient cache
useage turned out to be a showstopper for me at least.

	--- Pat

> -----Original Message-----
> From: Dan Adams [mailto:dan@ifactory.com]
> Sent: Friday, September 30, 2005 2:27 PM
> To: Tapestry users
> Subject: hivemind vs. tapestry
> 
> Okay, I've read a bit online about this (like Howard's post) and I don't
> want to start a flame war or anything but I'm thinking about design and
> need to make a decision before this project goes much further.
> 
> I'm currently using spring and hibernate and using services for all my
> hibernate code. Unfortunately, i found out I was using the
> session-per-operation antipattern (i know i know i'm sorry) which led me
> to think about how to implement session-per-request with detached
> objects (or even session-per-user-session would be better i think if
> thats really possible). So now I'm seriously wondering: is there an
> advantage to using both spring and hivemind and if so what is it? Or
> should I simply drop spring and using only hivemind services? I'm using
> spring beans for most everything right now.  One thing to consider is
> DI/IoC is the only thing I'm using spring for currently (i'm not using
> the spring aop or transactions) so as far as my usage I'm not sure if
> there is a big reason to stick with spring other than I like it.
> 
> But can some of you out there with more experience with
> tapestry/hivemind/spring/etc give me a little insight? Thanks. :)
> 
> --
> Dan Adams
> Software Engineer
> Interactive Factory
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org