On Wed, 20 Jun 2007 12:17:32 -0300, Michael Sims <[EMAIL PROTECTED]>
wrote:
Unless I'm mistaken, merge()'ing the same object into two different
Sessions isn't any more safe than using update() or lock(), so you still
have to deal with thread safety issues when using it.
I was just talking
Thiago H de Paula Figueiredo wrote:
> On Tue, 19 Jun 2007 18:24:10 -0300, Norman Franke <[EMAIL PROTECTED]>
> wrote:
>
>> 1. As Michael noted, they aren't thread safe.
>> 2. This really gets to a bigger issue, in that these objects aren't
>> valid outside of a session. Once the session closes, they
On Tue, 19 Jun 2007 18:24:10 -0300, Norman Franke <[EMAIL PROTECTED]> wrote:
1. As Michael noted, they aren't thread safe.
2. This really gets to a bigger issue, in that these objects aren't
valid outside of a session. Once the session closes, they are
technically invalid according to what I
Either should work, however.
On Jun 19, 2007, at 5:32 PM, Michael Sims wrote:
carlos f wrote:
Unless I am mistaken, which happens all the time, but it appears
that the
crux of his "thread safety" is, 1) storing detached instances on
the client
side -- I am assuming that "persists in the cli
On Jun 19, 2007, at 4:21 PM, carlos f wrote:
Norman Franke wrote:
My application only uses detached objects that it persists in the
client
page for change detection (to determine if the record they were
editing
changed while they were editing, which I flag as an
error.)
. . .
The first
carlos f wrote:
> Unless I am mistaken, which happens all the time, but it appears that the
> crux of his "thread safety" is, 1) storing detached instances on the client
> side -- I am assuming that "persists in the client page" is a reference to
> the ClientPropertyPersistenceStrategy
Sorry for m
On Jun 19, 2007, at 12:08 PM, carlos f wrote:
Norman Franke wrote:
In my case, my DAO has an
"assertUnchanged" method that throws an exception if the two objects
differ, e.g. my detached object and the one read from the database.
In this case, I tell the user that someone else changed their rec
Michael Sims wrote:
>
> I don't mean to speak for Norman, but the point of this thread has been
> that
> detached objects are not thread safe, so if you are going to store them in
> the
> HttpSession, you have to serialize access to it in order to avoid
> potentially trying
> to re-attach the sa
carlos f wrote:
> Why not rely on Hibernate's version support for detached objects and
> versioning?
[...]
> Why clone the detached object graph? Why not have the DAO reattach
> it to
> the session and save it -- assuming it passes your version check?
I don't mean to speak for Norman, but the poi
Geoff Callender wrote:
> You are right, it's a type of EJB. Your question is all about
> plumbing, and what I like about EJB 3 is that it does the plumbing
> for you, so only have to think about pages, business services, and
> entities.
[...]
> As you can tell, I am almost as enthusiastic about EJ
Sorry, my questions have nothing to do with Tapestry - put a few things you
mentioned piqued my interest.
Norman Franke wrote:
> In my case, my DAO has an
> "assertUnchanged" method that throws an exception if the two objects
> differ, e.g. my detached object and the one read from the databa
Hi Michael,
You are right, it's a type of EJB. Your question is all about
plumbing, and what I like about EJB 3 is that it does the plumbing
for you, so only have to think about pages, business services, and
entities. In other words, I suspect you'll find it easier than where
you're cur
Steve Shucker wrote:
> The only problem I've seen is if a user tries one of a
> few long operations and then changes their mind and clicks on
> something else. My filter still waits for the long operation to
> complete or timeout (configured to 20 seconds) before beginning the
> user's new request
I'm serializing the requests to prevent hibernate from trying to
associate an entity with more than one session. Most of the research
that led to this approach was done in the hibernate2/tapestry3 days, so
some of it may be outdated. I believe the rest of my state is
sufficiently thread-safe
The main issue with that is getPageService().getLink(false,
getPageName()) will return URLs too long for IE for my pages. Other
browsers like Safari grind to a near halt with really, really long
URLs, too.
-Norman
On Jun 16, 2007, at 10:03 AM, Thiago H de Paula Figueiredo wrote:
Em Fri, 1
On Jun 18, 2007, at 11:48 AM, Michael Sims wrote:
To persist a detached object, I call a clone() function on all of my
DB objects that converts it back to a normal POJO (from whatever
Hibernate does to it.)
That's a good idea, and I might end up doing the same thing. The
only thing
I don't
Hi Steve,
Steve Shucker wrote:
> I'm not sure if this will completely solve your problem, but I wrote
> my own WebRequestServicerFilter that only applies the
> session/transaction wrapping on non-asset requests.
Interesting! Thanks for that. There will still be some non-asset requests
in my app
Hi Geoff, thanks for the response,
Geoff Callender wrote:
> Do any of these problems exist if you get a session bean to do the
> work for you?
>
> For example, a page to edit the user, using a session bean called
> OrderService and an entity bean (using Hibernate if you like, as I
> do) called Ord
Hi,
Thanks for taking the time to respond, this is really helpful information.
Norman Franke wrote:
> My application only uses detached objects that it persists in the
> client page for change detection (to determine if the record they
> were editing changed while they were editing, which I flag
I'm not sure if this will completely solve your problem, but I wrote my
own WebRequestServicerFilter that only applies the session/transaction
wrapping on non-asset requests.
public void service(WebRequest request, WebResponse response,
WebRequestServicer servicer)
throws IOExceptio
Em Fri, 15 Jun 2007 19:16:30 -0300, Norman Franke <[EMAIL PROTECTED]>
escreveu:
The only glitches I noticed is when saving a record (i.e. not rolling
back) from a listener and returning another page (i.e. a direct
service.) I don't want them to be in the same session, since cached data
fr
Do any of these problems exist if you get a session bean to do the
work for you?
For example, a page to edit the user, using a session bean called
OrderService and an entity bean (using Hibernate if you like, as I
do) called Order.
When you're building the page...
IOrderServiceLocal or
I should note that I'm using Tapestry 4.0.x for my application. I'm
also pretty new to both Hibernate and Tapestry, so this may not be
the best. It does, however, seem to work well.
My application only uses detached objects that it persists in the
client page for change detection (to determ
23 matches
Mail list logo
