You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Norman Franke <no...@myasd.com> on 2009/07/14 01:04:12 UTC

T5 SSOs and Hibernate

I have a Session State Object that will hold some cached values from a  
database. I was hoping I could just inject Hibernate's Session into  
the SSO and use that, but it doesn't appear to work. I realize that  
SSOs are per-session and the Session is per thread. However, it seems  
the IoC should be able to handle this when I use @SessionState in my  
pages. However, it doesn't appear to work.

I have defined a contributeApplicationStateManager() in my AppModules  
that creates by SSO, since it uses an interface. But I can't inject  
the DAO there, of course.

What's the best way to do this? Get ahold of the registry and access  
the Session service that way? Alas, Google was no help.

Norman Franke
Answering Service for Directors, Inc.
www.myasd.com


Re: T5 SSOs and Hibernate

Posted by Norman Franke <no...@myasd.com>.
On Jul 13, 2009, at 9:17 PM, Thiago H. de Paula Figueiredo wrote:

> Em Mon, 13 Jul 2009 20:04:12 -0300, Norman Franke <no...@myasd.com>  
> escreveu:
>
>> I have a Session State Object that will hold some cached values  
>> from a
>> database. I was hoping I could just inject Hibernate's Session into
>> the SSO and use that, but it doesn't appear to work.
>
> An SSO is not a service, mixin nor component, so I don't expect it  
> to work. Anyway, I wouldn't never use Hibernate outside a DAO, but  
> this is another discussion. :) Try putting that logic that needs  
> Hibernate in a service instead of trying to put it in a SSO. SSOs  
> are meant to hold data, not logic.

In all likelihood I will use a DAO, but they still need a Hibernate  
Session, so it doesn't really change the problem. (Hence my previous  
posting on auto-registering DAOs, which I solved in a somewhat  
inelegant manner.) Even with it in a service, I still need to inject  
the service.

>> I realize that SSOs are per-session and the Session is per thread.  
>> However, it seems
>> the IoC should be able to handle this when I use @SessionState in my
>> pages.
>
> I don't follow you here. A SSO is nothing more than an object that  
> is automatically stored by Tapestry in a session. "Per thread" is  
> used in T-IoC in regard to services that are instantiated once per  
> thread that needs one instance.

Indeed, but they are both auto-created by Tapestry and thus similar in  
that they are all managed by Tapestry. The queries I plan on doing are  
time consuming, so I want to to a time-based cache. If the data is  
less than "n" seconds old, use it, otherwise re-read from the DB. I  
want to hide the details from the application pages, since they  
shouldn't have to care. That is more of a service, but services are  
per thread or singleton. There isn't a "per session" service. Granted  
I could do some singleton that injects the session, I guess, and use  
that as a key to a Map.

>> I have defined a contributeApplicationStateManager() in my AppModules
>> that creates by SSO, since it uses an interface. But I can't inject
>> the DAO there, of course.
>> What's the best way to do this? Get ahold of the registry and access
>> the Session service that way? Alas, Google was no help.
>
> Inject ObjectLocator and use its autobuild(Class clasz) method to  
> instantiate your SSO object. It'll do the injection in your SSO as  
> it does for services.

Makes sense. Will the reference to the DAOs and/or Session be kept up  
to date when I use the SSO in the next page refresh? (i.e. will it use  
the current session, not the one it used at creation?)

Thanks for the comments! This seems like a fairly common design  
pattern, and being new to T5, I'm attempting to figure out how to do  
this the "best" way, where best means the most transparent for for  
client pages and easy to maintain.

> -- 
> Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> http://www.arsmachina.com.br/thiago

Norman Franke
Answering Service for Directors, Inc.
www.myasd.com


Re: T5 SSOs and Hibernate

Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Mon, 13 Jul 2009 20:04:12 -0300, Norman Franke <no...@myasd.com>  
escreveu:

> I have a Session State Object that will hold some cached values from a
> database. I was hoping I could just inject Hibernate's Session into
> the SSO and use that, but it doesn't appear to work.

An SSO is not a service, mixin nor component, so I don't expect it to  
work. Anyway, I wouldn't never use Hibernate outside a DAO, but this is  
another discussion. :) Try putting that logic that needs Hibernate in a  
service instead of trying to put it in a SSO. SSOs are meant to hold data,  
not logic.

> I realize that SSOs are per-session and the Session is per thread.  
> However, it seems
> the IoC should be able to handle this when I use @SessionState in my
> pages.

I don't follow you here. A SSO is nothing more than an object that is  
automatically stored by Tapestry in a session. "Per thread" is used in  
T-IoC in regard to services that are instantiated once per thread that  
needs one instance.

> I have defined a contributeApplicationStateManager() in my AppModules
> that creates by SSO, since it uses an interface. But I can't inject
> the DAO there, of course.
> What's the best way to do this? Get ahold of the registry and access
> the Session service that way? Alas, Google was no help.

Inject ObjectLocator and use its autobuild(Class clasz) method to  
instantiate your SSO object. It'll do the injection in your SSO as it does  
for services.

-- 
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago

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