What's the risk of "stale" data?  Primary concern would be that someone updated the record between the time that you read the data, and when you try to perform your own update.  You can use the Hibernate / EJB3 strategy of optimistic locking with @Version (IIRC) to prevent stale data from accidental persistence.  If you're without Hibernate, there are well defined patterns to help you code an OL solution.
 
-jjk 


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Igor Vaynberg
Sent: Monday, July 17, 2006 10:52 AM
To: wicket-user@lists.sourceforge.net
Subject: Re: [Wicket-user] Wicket & Hibernate & Application Transactions

while merge is good for saving the bigger concern is stale data. you pass your pojo to the component, store it as a property, and some request later you read its property - which at this point will be stale because the pojo is detached from the session.

-Igor


On 7/17/06, Vincent Jenks <[EMAIL PROTECTED]> wrote:
I've been successful w/ exactly what Iman is concerned with - keeping
objects alive between requests just isn't necessary.  With
detachable-models, you can request your POJOs - and they effectively
become detached (outside of Hibernate session context).  You can pass
them between pages and persist them (putting them back into Hibernate
session context) by using merge() if you've updated their values.

I often save a round-trip by doing this w/ parent/child pages where I
pass the POJO to the detail page to view the child after it had
already been detached from the parent page.

On 7/17/06, Nathan Hamblen <[EMAIL PROTECTED]> wrote:
> As others have pointed out, the magic of IModel works better than you
> think (or thought) it does. I often have two constructors for pages, one
> taking bookmarkable parameters and another taking an IModel so that I
> don't always have to reload DB objects page to page. It's a cinch.
>
> http://databinder.net/wsvn/Databinder/recipe/trunk/src/main/java/example/RecipeBook.java?op=file
>
> But I get your point, when you say that this method is "mostly adapted
> to the old MVC style of web programming." You're right. The
> one-session-per-request style is the conventional wisdom that we should
> be questioning here on the cutting edge.
>
> On the other hand, we have to be careful of getting TOO far ahead of the
> curve. This listserv used to get about one question a week about
> Wicket's crazy practice of actually using the session store. Those Qs
> have turned into general concerns about about load, high volume, etc.
> The fact that Wicket has a system of detachable models that can
> repopulate themselves from DB each request cycle is enormously
> comforting to people.
>
> This system works very well and practically everyone uses it, but that
> shouldn't stop you from trying something else. Whatever you come up with
> just might be the way we all do it in a few years, when server resources
> dwarf those available today. I like IModels fine, and will like them
> even more when they're strongly typed, but I'll admit it would be easier
> to just pass around the objects they contain. Significantly easier for
> new users.
>
> So please do give it a shot. (I'm assuming your app is high-complexity,
> low-volume, or that you have small data objects.) I can't think of
> anything in Wicket that would slow you down, other than the minor
> annoyance of having to wrap objects in new Model(Serializable o) before
> passing them to some framework components.
>
> And let us know how it goes!
>
> Nathan
>
>
> Iman Rahmatizadeh wrote:
> > The problem with #1 is, first its a bit ugly, second you discard every
> > persistent instance in each cycle (which is less efficient than #2 or
> > #3), third you lose the advantages of working & passing POJO's between
> > pages, Like you would call 'new ProfilePage(person.getId())' instead of
> > 'new ProfilePage(person))' and retrieve the person from database again
> > in the profile page. As Nathan said, despite the disadvantages, it's the
> > easiest and the most straight forward, and mostly adapted to the old MVC
> > style of web programming.
> > With wicket, I would like to pass objects around to pages and methods,
> > keep them in memory during the unit of work, and persist the changes at
> > the end. The problem is I make a new Hibernate Session in each request
> > cycle, so I have to re-attach the objects from the previous cycle to the
> > new Hibernate Session each time (as in #2). This can get quite
> > cumbersome and would easily get out of control.
> > With all that said , I guess I'm alone in this case and everybody agrees
> > on using #1. Still if anybody has any experience with #2 or #3, I would
> > be happy to know about it.
> >
> > Iman
>
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Wicket-user mailing list
> Wicket-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wicket-user
>


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Reply via email to