Expanding on what James said and following up on a hint given by Howard
in an earlier thread, I have been using the approach of injecting the
ASO into services using the following approach: 1) create a proxy object
that implements the same interface as the ASO, 2) the proxy is a
threaded/pooled hivemind service, 3) the ApplicationStateManager is
injected into the proxy, 4) when a method is called on the proxy, it
looks up the ASO (which is the correct one due to the proxy being
threaded) and passes through the method call.
I inject the proxy into any service/dao that needs information from the ASO.
It would be a nice enhancement in tapestry if such ASO proxies could be
automatically created.
-- Mark
James Carman wrote:
Create a service which returns the "current" business object. That service
can lookup the ASO and get the key. Then, your client code just calls the
service.
-----Original Message-----
From: Paul Field [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 02, 2006 11:46 AM
To: tapestry-user@jakarta.apache.org
Subject: Is it safe to inject HiveMind services into an ASO?
I would like to use an ASO that contains a business object. However, I
can't store the business object directly in the ASO because (a) it will be
serialized into the session (along with a lot of related objects) (b) it is
associated with a particular database session so needs to be re-created on
each request to ensure consistency.
So, instead, I'm storing the key of the business object in the ASO. However,
that means that every piece of client code needs to know how to turn the key
into the business object - in my case, by knowing a data access object (DAO)
that can do it for them. So, here's an example ASO showing my current
approach:
public class Preferences implements Serializable {
private long regionId;
public Region getRegion(RegionDAO dao) {
return dao.getRegionForId(regionId);
}
public void setRegion(Region region) {
regionId = region.getId();
}
}
What I would really like to do is use HiveMind to inject the DAO and make my
ASO something like this:
public class Preferences implements Serializable {
private transient RegionDAO dao;
private long regionId;
public void setRegionDAO(RegionDAO newDao) {
dao = newDao;
}
public Region getRegion() {
return dao.getRegionForId(regionId);
}
public void setRegion(Region region) {
regionId = region.getId();
}
}
So, I'd like to know if this is a safe thing to do. Assuming the preferences
might get serialized and re-loaded by the app server or passed around a
cluster, how do I make sure that the RegionDAO stays injected but doesn't
end up serializing itself (unless it can serialize some kind of stub).
Thanks,
Paul
------------------
Paul Field
Global Markets Research IT
Deutsche Bank
---
This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
