You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Alfonso Quiroga <al...@gmail.com> on 2009/11/12 07:49:24 UTC
Hibernate question
Yes, I know, this should be in a hibernate mail-list, but I don't know
anyone, and I have a basic question
I use T5 + hibernate, I have hibernate-session per web-request (it's
just a RequestFilter that closes the current hibernate session)
My question is this:
if I have a User object (or anything) in the Tapestry5 session... what
happens in diferent requests? I mean, if I have hibernate-session per
request, do I need to MERGE this objects with the current
hibernate-session? because this objects were created with another
hibernate session. Thanks!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Hibernate question
Posted by "Juan E. Maya" <ma...@gmail.com>.
u can also let Tapestry-Hibernate take care of that for u.
On Fri, Nov 13, 2009 at 3:18 PM, Szemere Szemere
<sz...@googlemail.com> wrote:
> Afaik any Hibernate object stored in the HTTPSession will be
> Hibernate-detached between HTTP requests. It is not refreshed/merged
> automatically on a new HTTP request, so it will be outside the Hibernate
> session on the second request which is probably not what you want.
>
> It is generally a much better idea to store the object id in the session and
> recreate it at the beginning of each new HTTP request. Tapestry has some
> features to make this easy for you, but that's beyond my expertise (search
> the mailing list).
>
> Szemere
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Hibernate question
Posted by Alfonso Quiroga <al...@gmail.com>.
Juan Maya: thanks a lot!!
On Mon, Nov 16, 2009 at 4:39 PM, Juan E. Maya <ma...@gmail.com> wrote:
> Tapestry-hibernates contributes a new strategy "entity". This way only
> the id of hibernate entities are saved on the session and the module
> takes care of recreating the object during the next request.
>
> Check: http://tapestry.apache.org/tapestry5/tapestry-hibernate/userguide.html
> look for Using @Persist with entities.
>
> If u want to put the entities ids in the sesssion by yourself u could
> still make use of the HibernateEntityValueEncoder provided by
> Tapestry-hibernate to recreate the entity.
>
> On Mon, Nov 16, 2009 at 4:22 PM, Alfonso Quiroga <al...@gmail.com> wrote:
>> Thanks for replies! I think the easier approach is to save the object
>> ID in the session, as Szemere said. Someone has used
>> tapestry-hibernate and knows what happens in this cases? it stores the
>> real objetct in web session and then it merges with de new
>> hib-session? thanks again
>>
>> On Mon, Nov 16, 2009 at 2:36 AM, Jonathan Barker
>> <jo...@gmail.com> wrote:
>>> This also depends on your objectives.
>>>
>>> If you have a detached entity in your session, then you have the option to
>>> check for changes in the DB when you try to save, and then present some kind
>>> of conflict resolution screen, rather than blindly overwriting or accepting
>>> changes made in another session. Having said that, "blindly accepting /
>>> overwriting" is usually fine for my applications and I *usually* store the
>>> id.
>>>
>>> Jonathan
>>>
>>>
>>> On Fri, Nov 13, 2009 at 9:18 AM, Szemere Szemere <
>>> szemereszemere@googlemail.com> wrote:
>>>
>>>> Afaik any Hibernate object stored in the HTTPSession will be
>>>> Hibernate-detached between HTTP requests. It is not refreshed/merged
>>>> automatically on a new HTTP request, so it will be outside the Hibernate
>>>> session on the second request which is probably not what you want.
>>>>
>>>> It is generally a much better idea to store the object id in the session
>>>> and
>>>> recreate it at the beginning of each new HTTP request. Tapestry has some
>>>> features to make this easy for you, but that's beyond my expertise (search
>>>> the mailing list).
>>>>
>>>> Szemere
>>>>
>>>
>>>
>>>
>>> --
>>> Jonathan Barker
>>> ITStrategic
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Hibernate question
Posted by "Juan E. Maya" <ma...@gmail.com>.
Tapestry-hibernates contributes a new strategy "entity". This way only
the id of hibernate entities are saved on the session and the module
takes care of recreating the object during the next request.
Check: http://tapestry.apache.org/tapestry5/tapestry-hibernate/userguide.html
look for Using @Persist with entities.
If u want to put the entities ids in the sesssion by yourself u could
still make use of the HibernateEntityValueEncoder provided by
Tapestry-hibernate to recreate the entity.
On Mon, Nov 16, 2009 at 4:22 PM, Alfonso Quiroga <al...@gmail.com> wrote:
> Thanks for replies! I think the easier approach is to save the object
> ID in the session, as Szemere said. Someone has used
> tapestry-hibernate and knows what happens in this cases? it stores the
> real objetct in web session and then it merges with de new
> hib-session? thanks again
>
> On Mon, Nov 16, 2009 at 2:36 AM, Jonathan Barker
> <jo...@gmail.com> wrote:
>> This also depends on your objectives.
>>
>> If you have a detached entity in your session, then you have the option to
>> check for changes in the DB when you try to save, and then present some kind
>> of conflict resolution screen, rather than blindly overwriting or accepting
>> changes made in another session. Having said that, "blindly accepting /
>> overwriting" is usually fine for my applications and I *usually* store the
>> id.
>>
>> Jonathan
>>
>>
>> On Fri, Nov 13, 2009 at 9:18 AM, Szemere Szemere <
>> szemereszemere@googlemail.com> wrote:
>>
>>> Afaik any Hibernate object stored in the HTTPSession will be
>>> Hibernate-detached between HTTP requests. It is not refreshed/merged
>>> automatically on a new HTTP request, so it will be outside the Hibernate
>>> session on the second request which is probably not what you want.
>>>
>>> It is generally a much better idea to store the object id in the session
>>> and
>>> recreate it at the beginning of each new HTTP request. Tapestry has some
>>> features to make this easy for you, but that's beyond my expertise (search
>>> the mailing list).
>>>
>>> Szemere
>>>
>>
>>
>>
>> --
>> Jonathan Barker
>> ITStrategic
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Hibernate question
Posted by Alfonso Quiroga <al...@gmail.com>.
Thanks for replies! I think the easier approach is to save the object
ID in the session, as Szemere said. Someone has used
tapestry-hibernate and knows what happens in this cases? it stores the
real objetct in web session and then it merges with de new
hib-session? thanks again
On Mon, Nov 16, 2009 at 2:36 AM, Jonathan Barker
<jo...@gmail.com> wrote:
> This also depends on your objectives.
>
> If you have a detached entity in your session, then you have the option to
> check for changes in the DB when you try to save, and then present some kind
> of conflict resolution screen, rather than blindly overwriting or accepting
> changes made in another session. Having said that, "blindly accepting /
> overwriting" is usually fine for my applications and I *usually* store the
> id.
>
> Jonathan
>
>
> On Fri, Nov 13, 2009 at 9:18 AM, Szemere Szemere <
> szemereszemere@googlemail.com> wrote:
>
>> Afaik any Hibernate object stored in the HTTPSession will be
>> Hibernate-detached between HTTP requests. It is not refreshed/merged
>> automatically on a new HTTP request, so it will be outside the Hibernate
>> session on the second request which is probably not what you want.
>>
>> It is generally a much better idea to store the object id in the session
>> and
>> recreate it at the beginning of each new HTTP request. Tapestry has some
>> features to make this easy for you, but that's beyond my expertise (search
>> the mailing list).
>>
>> Szemere
>>
>
>
>
> --
> Jonathan Barker
> ITStrategic
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Hibernate question
Posted by Jonathan Barker <jo...@gmail.com>.
This also depends on your objectives.
If you have a detached entity in your session, then you have the option to
check for changes in the DB when you try to save, and then present some kind
of conflict resolution screen, rather than blindly overwriting or accepting
changes made in another session. Having said that, "blindly accepting /
overwriting" is usually fine for my applications and I *usually* store the
id.
Jonathan
On Fri, Nov 13, 2009 at 9:18 AM, Szemere Szemere <
szemereszemere@googlemail.com> wrote:
> Afaik any Hibernate object stored in the HTTPSession will be
> Hibernate-detached between HTTP requests. It is not refreshed/merged
> automatically on a new HTTP request, so it will be outside the Hibernate
> session on the second request which is probably not what you want.
>
> It is generally a much better idea to store the object id in the session
> and
> recreate it at the beginning of each new HTTP request. Tapestry has some
> features to make this easy for you, but that's beyond my expertise (search
> the mailing list).
>
> Szemere
>
--
Jonathan Barker
ITStrategic
Re: Hibernate question
Posted by Szemere Szemere <sz...@googlemail.com>.
Afaik any Hibernate object stored in the HTTPSession will be
Hibernate-detached between HTTP requests. It is not refreshed/merged
automatically on a new HTTP request, so it will be outside the Hibernate
session on the second request which is probably not what you want.
It is generally a much better idea to store the object id in the session and
recreate it at the beginning of each new HTTP request. Tapestry has some
features to make this easy for you, but that's beyond my expertise (search
the mailing list).
Szemere
Re: Hibernate question
Posted by Alfonso Quiroga <al...@gmail.com>.
Actually I have one hibernate session in one request. I think the
problem should be when I use hibernate objects in the WEB session,
thanks
On Thu, Nov 12, 2009 at 3:56 AM, Angelo Chen <an...@yahoo.com.hk> wrote:
>
> Hi,
>
> If you use Tapestry-Hibernate, it manages session for you, so there is only
> one session in one request, i don't think you have to merge them, just put
> @CommitAfter. one thing I notice, if table is MyIsam, it is always
> committed, for InoDB, u need @CommitAfter.
>
> A.C
>
>
> Alfonso Quiroga wrote:
>>
>> Yes, I know, this should be in a hibernate mail-list, but I don't know
>> anyone, and I have a basic question
>>
>> I use T5 + hibernate, I have hibernate-session per web-request (it's
>> just a RequestFilter that closes the current hibernate session)
>> My question is this:
>> if I have a User object (or anything) in the Tapestry5 session... what
>> happens in diferent requests? I mean, if I have hibernate-session per
>> request, do I need to MERGE this objects with the current
>> hibernate-session? because this objects were created with another
>> hibernate session. Thanks!
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>
>
> --
> View this message in context: http://old.nabble.com/Hibernate-question-tp26314262p26314306.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Hibernate question
Posted by Angelo Chen <an...@yahoo.com.hk>.
Hi,
If you use Tapestry-Hibernate, it manages session for you, so there is only
one session in one request, i don't think you have to merge them, just put
@CommitAfter. one thing I notice, if table is MyIsam, it is always
committed, for InoDB, u need @CommitAfter.
A.C
Alfonso Quiroga wrote:
>
> Yes, I know, this should be in a hibernate mail-list, but I don't know
> anyone, and I have a basic question
>
> I use T5 + hibernate, I have hibernate-session per web-request (it's
> just a RequestFilter that closes the current hibernate session)
> My question is this:
> if I have a User object (or anything) in the Tapestry5 session... what
> happens in diferent requests? I mean, if I have hibernate-session per
> request, do I need to MERGE this objects with the current
> hibernate-session? because this objects were created with another
> hibernate session. Thanks!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
--
View this message in context: http://old.nabble.com/Hibernate-question-tp26314262p26314306.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org