click-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bob Schellink <>
Subject Re: Click web architecture questions - services, transactions, etc.
Date Tue, 27 Apr 2010 12:48:16 GMT
Hi Georgi,

On 27/04/2010 18:53, gdenchev wrote:
> Still, I am unsure how to solve some high level architectural questions with
> regards to Click and its lifecycle.
> I am going to ask here hoping that someone has been that road before.
> (Please note that I am a long time Struts1 user with decent knowledge of
> Spring)
> So, here goes:
> 1. Service layer (connected somehow to 2) - it it clearly a good practice to
> isolate business logic from view/controller logic. I am thinking Spring
> beans here, and we fortunately we have the means of integrating Spring and
> Click using custom resolvers in Click Extras. The resolver (currently)
> resolves Click pages as Spring non-singleton (prototype) beans and all other
> components as Spring singleton beans (needs tweaking to extract metadata
> from Spring configuration).
> Now, the question: I suppose this is OK with Click stateless pages, but will
> it behave nicely with stateful pages. I would love to hear some opinions
> from the people with extensive Click knowledge.

Stateful pages are stored in the HttpSession so there could be issues if the services are
direclty from the Page. For example if the session is serialized to disk the services are
as well. This might be acceptable but I assume it is not. There are two possible alternatives:
mark the services as transient so they are not serialized to disk or 2) lookup the services
from the
ApplicationContext instead.

I believe 1) doesn't currently work across server restarts if the session is
serialized/deserialized, as the service references are not re-injected by Spring. I'd be interested
to know if Spring has a way of dealing with this issue.

The ApplicationContext on the other hand is always re-injected by the SpringClickServlet and
will be
available after a server restart. If you look at the Click examples you'll notice this pattern
for stateful pages:

> 2. Transaction management (connected somehow to 1) - we have some common
> logic dealing with ORM/database transaction exception handling and want to
> employ declarative (or at least common for the majority of pages)
> transaction management. I have read numerous materials on the topic and
> currently think that JBoss Seam has a good approach with its JSF
> integration. Essentially Seam opens two transactions per request (if needed)
> - one read/write transaction for the part before response rendering, and one
> read-only transaction for the response rendering phase (
> (
> )
> Now the question: Has someone considered using this declarative approach
> with Click?

We use Apache Cayenne which doesn't suffer from the Lazy load exception so I haven't given
too much
thought to this problem lately :). It is an interesting topic however.

It should be possible to implement two phased transactions in a SpringClickServlet subclass
customizing the Click lifecycle method: #processPage. The method is fairly straightforward
if you
need to customize it:

The upcoming 2.2.0 release has a PageInterceptor which could make such an implementation simpler:

I'd be interested to know your findings.

Kind regards


View raw message