Martijn,
I see your point about users clicking fast and causing an exception if
I keep a User in the session (transient or otherwise). I too would be
curious to see some example code of how you handle the situation.
Thanks,
Tauren
On Mon, Feb 23, 2009 at 11:47 PM, Alexander Lohse
I already told that in this thread: move your entity storage to your
custom request cycle, and just keep the entity identifier in your
custom session. then always access the entity either directly from the
request cycle, or through delegates from your session. There's no
rocket science here.
Jumping in here part way through the thread, so apologies if you've
covered this already.
What we do is simply store a key that represents the user (and maybe a
small amount of data that is accessed about the user on every page).
In general we find that our persistence is much more reliable
Having access to the complete user object, comes in handy if you use
compound models.. Like the CompundPropertyModel...
But I see your point.. But it's also sort of what the LDM does, store some
kind of identifier and then looks up the user if its not already loaded..
2009/2/23 Brill Pappin
Hi Martijn,
could you paste some short example code to point out how to load and
access a UserModel in the requestcycle?
Regards,
Alex
Am 23.02.2009 um 08:42 schrieb Martijn Dashorst:
Storing the user in a field of Session is wrong. Didn't you read the
concurrency caveats I posted
I think it looks fine.. However I'd delegate the creation of the model to
session...
page
setDefaultModel(getSession().getUserModel())
session:
function DetachableUserModel getUserModel()
{
return new DetachableUserModel(getSession().getUser(),userDao);
}
2009/2/20 Tauren Mills
Storing the user in a field of Session is wrong. Didn't you read the
concurrency caveats I posted earlier?
When users click fast enough, you'll get Hibernate exceptions pretty
soon. Entity instances can't be shared between multiple threads.
Putting them in the Session exposes them to that threat.
Hi Tauren
I've done something similar.. Have no trouble with..
Disclaimer, below code are really ugly and I need to clean it up...
package zeuzgroup.application;
import org.apache.wicket.Request;
import org.apache.wicket.authentication.AuthenticatedWebSession;
import
Hehe, my answer are the same as Martijn. Use the ID as key in LDM, see
below.
public class BaseEntityDetachableModel E extends BaseEntity extends
LoadableDetachableModel {
@SpringBean(name = dBDao)
protected IDBDao dBDao;
private Long id;
private ClassE clazz;
public
move the IModelPerson to your custom request cycle, otherwise you'll
run into the issues I've pointed out earlier where on thread detaches
while another attaches. Storing entities in your session when your
interested in maintaining them with your entitymanager is BAD, even if
you put it in a LDM.
Ok, thanks for the tip...
2009/2/20 Martijn Dashorst martijn.dasho...@gmail.com
move the IModelPerson to your custom request cycle, otherwise you'll
run into the issues I've pointed out earlier where on thread detaches
while another attaches. Storing entities in your session when your
Hi Martijn,
your reply reminds me of a question I always wanted to ask: is it safe
to use IModels outside of components with their defined lifecycle and
getDefaultModel() method? We'd like to use models everywhere we have
to retrieve domain objects, be it configuration or, as in this thread,
There are several types of safety:
- making sure they are detached?
- making sure they are only used inside one thread?
- ...
Detaching outside of the wicket component tree's default model slot is
not automatic: you have to do that yourself (override ondetach for
example). AFAIK we'll be
Nino and Martijn,
Thanks for the help. Last night I was looking through the elephas
code and found a solution that I think will work for me. It doesn't
store an LDM in the session, but stores an identifier and a
*transient* instance of User. This seems like an effective solution
to me. I tried
The WIA book and other example apps I've found online often show a
User object being stored in the session:
class BlogSession extends WebSession {
private User user;
}
But does it make sense to do this if your User object is loaded from a
persistence layer (Hibernate) and can contain a large
Access to session is not thread safe: resources, and request
setup/teardown will give you headaches (ever tried to attach one
entity instance to two hibernate sessions?). We store the ID of the
entity in the session, and load it in the requestcycle (and get the
instance from there).
Martijn
On
Martin,
Thanks for the response! I was actually just modifying my
implementation to store just the ID in the session and was trying to
figure out where the best place to load it would be. I was trying to
load it in a page constructor, but was finding that doesn't always
work. So I'll explore
17 matches
Mail list logo
