You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Bruno Santos <bi...@gmail.com> on 2009/09/11 22:22:46 UTC
Exception handling after violation of unique constraint
Thanks for your answer, i learned a bit more of tapestry.
Now i have one more problem, not exactly related but in the same area.
I have
void onValidateForm() {
if (entity.getId().longValue() == 0l) {
league.setId(null);
}
System.out.println("OnValidateForm");
try {
_entityDAO.persist(entity);
} catch (RuntimeException ex) {
leagueForm.recordError("error"); // EXCEPTION IS THROWN - THE TEST
I'M DOING HITS THE UNIQUE CONSTRAINT
}
}
void onFailure() {
_entityDAO.abort();
System.out.println("onFailure");
}
And this is working except it doesn't refresh the form with the errors
i added on the onValidate
When i use:
Object onFailure() {
_entityDAO.abort();
System.out.println("onFailure");
return this;
}
The following exception is thrown:
Caused by: org.apache.tapestry5.ioc.internal.util.TapestryException:
null id in pt.hi.asianconnect.entities.League entry (don't flush the
Session after an exception occurs) [at
classpath:pt/hi/asianconnect/components/generated/CreateUpdateLeague.tml,
line 12]
at org.apache.tapestry5.internal.bindings.PropBinding.get(PropBinding.java:62)
at org.apache.tapestry5.internal.structure.InternalComponentResourcesImpl$1.read(InternalComponentResourcesImpl.java:510)
... 119 more
Caused by: org.hibernate.AssertionFailure: null id in
pt.hi.asianconnect.entities.League entry (don't flush the Session
after an exception occurs)
at org.hibernate.event.def.DefaultFlushEntityEventListener.checkId(DefaultFlushEntityEventListener.java:78)
at org.hibernate.event.def.DefaultFlushEntityEventListener.getValues(DefaultFlushEntityEventListener.java:187)
at org.hibernate.event.def.DefaultFlushEntityEventListener.onFlushEntity(DefaultFlushEntityEventListener.java:143)
at org.hibernate.event.def.AbstractFlushingEventListener.flushEntities(AbstractFlushingEventListener.java:219)
at org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:99)
at org.hibernate.event.def.DefaultAutoFlushEventListener.onAutoFlush(DefaultAutoFlushEventListener.java:58)
at org.hibernate.impl.SessionImpl.autoFlushIfRequired(SessionImpl.java:996)
at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1589)
at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:306)
at DefaultHibernateDAO.findByCriteria(DefaultHibernateDAO.java:104)
The abort method from DAO was an experiment of mine wich calls
hibernatesessionmanager.abort(). From what i understand, what happens
is when the page is to be renderered, the hibernatesessionmanager
that's used has "dirty" data that's why it uses
SessionImpl.autoFlushIfRequired when i'm fetching data to refill the
page, hence my experiment on calling the abort from
hibernatesessionmanger, still this doesn't do it and i don't know how
to "clean" data from the sessionmanager.
Ideas anyone?
One importante note, the test i'm doing implies that the my method
that saveOrUpdate the entity is "hitting" a unique constraint
On Thu, Sep 10, 2009 at 11:20 PM, Kalle Korhonen
<ka...@gmail.com> wrote:
> You should instead try storing it onValidate. If it fails, you should
> record an error and if it succeeds you should commit only in onSuccess
> (but the method body can be otherwise empty).
>
> Kalle
>
>
> On Thu, Sep 10, 2009 at 2:55 PM, Bruno Santos <bi...@gmail.com> wrote:
>> Good evening,
>>
>> I have a form using a zone and i have @CommitAfter on the
>> onSubmitFromEntityForm()
>>
>> <t:form t:id="entityForm" zone="entityZone">
>> <input type="text" t:type="textfield" t:id="name"
>> t:value="entity.name" />
>> </t:form>
>>
>> @CommitAfter
>> Object onSubmitFromEntityForm() {
>> ....
>> try {
>> entityDao.persist(entity);
>> } catch (exception ex) {
>> // handle exception
>> }
>> }
>>
>> altough i'm handling the exception the @CommitAfter creates a new
>> exception since it tries to commit something that's not in transaction
>> due to catched exception.
>>
>> How to deal with this? Is there a way to avoid the @CommitAfter to
>> execute ... a handler i can use? I think i can remove the @CommitAfter
>> but don't believe this should be first option.
>>
>> ---------------------------------------------------------------------
>> 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: Exception handling after violation of unique constraint
Posted by Geoff Callender <ge...@gmail.com>.
Agreed. Any number of exceptions can occur when you commit, regardless
of what queries you've run in the same transaction. That's the nature
of multi-user systems, unless of course you want to set the
transaction isolation level to serialize (not usually recommended).
As for using onValidate() versus onSuccess(), I'd avoid doing anything
but page navigation in onSuccess() because ionSuccess() can't report
exceptions properly (https://issues.apache.org/jira/browse/
TAPESTRY-1972).
On 13/09/2009, at 4:13 PM, Hilco Wijbenga wrote:
> 2009/9/12 Thiago H. de Paula Figueiredo <th...@gmail.com>:
>> Em Sat, 12 Sep 2009 17:38:43 -0300, Bruno Santos
>> <bi...@gmail.com>
>> escreveu:
>>
>>> Well, even if i do:
>>>
>>> league = new League();
>>> league.setName("repeated name");
>>
>> Unique constraints like this should be checked by you *before*
>> sending an
>> insert or update to the database.
>
> Would that not simply create a race condition? Thread A checks XYZ,
> thread B (checks and) writes XYZ, thread A tries to write XYZ and
> BOOM.
>
> Shouldn't database constraint checking be a job for the database, not
> for the application? The right tool for the job and all that. :-)
>
> (That doesn't mean you can't check prior to inserting/updating but you
> should never *rely* on it.)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
Re: Exception handling after violation of unique constraint
Posted by Hilco Wijbenga <hi...@gmail.com>.
2009/9/12 Thiago H. de Paula Figueiredo <th...@gmail.com>:
> Em Sat, 12 Sep 2009 17:38:43 -0300, Bruno Santos <bi...@gmail.com>
> escreveu:
>
>> Well, even if i do:
>>
>> league = new League();
>> league.setName("repeated name");
>
> Unique constraints like this should be checked by you *before* sending an
> insert or update to the database.
Would that not simply create a race condition? Thread A checks XYZ,
thread B (checks and) writes XYZ, thread A tries to write XYZ and
BOOM.
Shouldn't database constraint checking be a job for the database, not
for the application? The right tool for the job and all that. :-)
(That doesn't mean you can't check prior to inserting/updating but you
should never *rely* on it.)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Exception handling after violation of unique constraint
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Sat, 12 Sep 2009 17:38:43 -0300, Bruno Santos <bi...@gmail.com>
escreveu:
> Well, even if i do:
>
> league = new League();
> league.setName("repeated name");
Unique constraints like this should be checked by you *before* sending an
insert or update to the database.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Exception handling after violation of unique constraint
Posted by Bruno Santos <bi...@gmail.com>.
Well, even if i do:
league = new League();
league.setName("repeated name");
I still have same problem, even without that piece of code.
Everything works fine with Create/Update of entity if saveorupdate
doesn't violate any constraint.
On Sat, Sep 12, 2009 at 7:34 PM, Kalle Korhonen
<ka...@gmail.com> wrote:
> Yes, but the problem originates from this:
> if (entity.getId().longValue() == 0l) {
> league.setId(null);
> }
> You can't make that league object a new entity just by nullifying it's
> id. Try creating a new league if you need to. Later on, since the
> saveOrUpdate failed, the null id causes the problem in
> DefaultHibernateDAO because that object is already Hibernate's
> session.
>
> Kalle
>
> On Sat, Sep 12, 2009 at 8:47 AM, Bruno Santos <bi...@gmail.com> wrote:
>> The question is i'm not trying to flush anything, i do (through DAO)
>> session.saveOrUpdate, catch the exception and the only thing i do
>> besides registering the error on the form is returning this (the page
>> i'm at) wich causes (i guess) tapestry to query database to fill data
>> for selectmodels. And, at this point i think tapestry uses the same
>> session it used for the saveorupdate and "list" trys to flush if
>> there's "dirty data".
>>
>> On Sat, Sep 12, 2009 at 3:02 AM, Kalle Korhonen
>> <ka...@gmail.com> wrote:
>>> I'm using the plain hibernate Session (shadow) and the pattern works
>>> great for me. But I think your problem is actually in "(don't flush
>>> the
>>> Session after an exception occurs)". You are doing something odd since
>>> you need to nullify the id. For a new object, the id should normally
>>> be null. Tapestry is already thinking it's a previously persisted
>>> entity.
>>>
>>> Kalle
>>>
>>>
>>> On Fri, Sep 11, 2009 at 2:30 PM, Bruno Santos <bi...@gmail.com> wrote:
>>>> Hello,
>>>>
>>>> Well, the reason should be that with persist in validate() i validate
>>>> that the entity that's inserted doesn't conflict with any database
>>>> constraint like in this case and the onsucess isn't fired wich in the
>>>> case a constraint is violated it doesn't seem to make sense.
>>>>
>>>> Anyway, even if i use the code on the onSucess method it comes down to
>>>> the same issue, the exception is thrown whenever i try to do any
>>>> operation that requires hibernate (problem should be in
>>>> hibernatesessionmanager, not being "clean").
>>>>
>>>> One way i guess it could solve the problem is discarding the current
>>>> hibernatesessionmanager, invalidate it somehow, but i don't know if
>>>> that's possible.
>>>>
>>>> Thanks
>>>>
>>>> On Fri, Sep 11, 2009 at 10:15 PM, Sven Homburg <ho...@googlemail.com> wrote:
>>>>> what is your reason, that you want to persist the enity
>>>>> in the validation event?
>>>>>
>>>>> i think its more clear to persist it in the onSuccess event method
>>>>>
>>>>> with regards
>>>>> Sven Homburg
>>>>> Founder of the Chenille Kit Project
>>>>> http://www.chenillekit.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 2009/9/11 Bruno Santos <bi...@gmail.com>
>>>>>
>>>>>> Thanks for your answer, i learned a bit more of tapestry.
>>>>>>
>>>>>> Now i have one more problem, not exactly related but in the same area.
>>>>>>
>>>>>> I have
>>>>>>
>>>>>> void onValidateForm() {
>>>>>> if (entity.getId().longValue() == 0l) {
>>>>>> league.setId(null);
>>>>>> }
>>>>>>
>>>>>> System.out.println("OnValidateForm");
>>>>>> try {
>>>>>> _entityDAO.persist(entity);
>>>>>> } catch (RuntimeException ex) {
>>>>>> leagueForm.recordError("error"); // EXCEPTION IS
>>>>>> THROWN - THE TEST
>>>>>> I'M DOING HITS THE UNIQUE CONSTRAINT
>>>>>> }
>>>>>>
>>>>>> }
>>>>>>
>>>>>> void onFailure() {
>>>>>> _entityDAO.abort();
>>>>>> System.out.println("onFailure");
>>>>>> }
>>>>>>
>>>>>> And this is working except it doesn't refresh the form with the errors
>>>>>> i added on the onValidate
>>>>>>
>>>>>> When i use:
>>>>>>
>>>>>> Object onFailure() {
>>>>>> _entityDAO.abort();
>>>>>> System.out.println("onFailure");
>>>>>> return this;
>>>>>> }
>>>>>>
>>>>>> The following exception is thrown:
>>>>>>
>>>>>> Caused by: org.apache.tapestry5.ioc.internal.util.TapestryException:
>>>>>> null id in pt.hi.asianconnect.entities.League entry (don't flush the
>>>>>> Session after an exception occurs) [at
>>>>>> classpath:pt/hi/asianconnect/components/generated/CreateUpdateLeague.tml,
>>>>>> line 12]
>>>>>> at
>>>>>> org.apache.tapestry5.internal.bindings.PropBinding.get(PropBinding.java:62)
>>>>>> at
>>>>>> org.apache.tapestry5.internal.structure.InternalComponentResourcesImpl$1.read(InternalComponentResourcesImpl.java:510)
>>>>>> ... 119 more
>>>>>> Caused by: org.hibernate.AssertionFailure: null id in
>>>>>> pt.hi.asianconnect.entities.League entry (don't flush the Session
>>>>>> after an exception occurs)
>>>>>> at
>>>>>> org.hibernate.event.def.DefaultFlushEntityEventListener.checkId(DefaultFlushEntityEventListener.java:78)
>>>>>> at
>>>>>> org.hibernate.event.def.DefaultFlushEntityEventListener.getValues(DefaultFlushEntityEventListener.java:187)
>>>>>> at
>>>>>> org.hibernate.event.def.DefaultFlushEntityEventListener.onFlushEntity(DefaultFlushEntityEventListener.java:143)
>>>>>> at
>>>>>> org.hibernate.event.def.AbstractFlushingEventListener.flushEntities(AbstractFlushingEventListener.java:219)
>>>>>> at
>>>>>> org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:99)
>>>>>> at
>>>>>> org.hibernate.event.def.DefaultAutoFlushEventListener.onAutoFlush(DefaultAutoFlushEventListener.java:58)
>>>>>> at
>>>>>> org.hibernate.impl.SessionImpl.autoFlushIfRequired(SessionImpl.java:996)
>>>>>> at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1589)
>>>>>> at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:306)
>>>>>> at DefaultHibernateDAO.findByCriteria(DefaultHibernateDAO.java:104)
>>>>>>
>>>>>>
>>>>>> The abort method from DAO was an experiment of mine wich calls
>>>>>> hibernatesessionmanager.abort(). From what i understand, what happens
>>>>>> is when the page is to be renderered, the hibernatesessionmanager
>>>>>> that's used has "dirty" data that's why it uses
>>>>>> SessionImpl.autoFlushIfRequired when i'm fetching data to refill the
>>>>>> page, hence my experiment on calling the abort from
>>>>>> hibernatesessionmanger, still this doesn't do it and i don't know how
>>>>>> to "clean" data from the sessionmanager.
>>>>>>
>>>>>> Ideas anyone?
>>>>>>
>>>>>> One importante note, the test i'm doing implies that the my method
>>>>>> that saveOrUpdate the entity is "hitting" a unique constraint
>>>>>>
>>>>>> On Thu, Sep 10, 2009 at 11:20 PM, Kalle Korhonen
>>>>>> <ka...@gmail.com> wrote:
>>>>>> > You should instead try storing it onValidate. If it fails, you should
>>>>>> > record an error and if it succeeds you should commit only in onSuccess
>>>>>> > (but the method body can be otherwise empty).
>>>>>> >
>>>>>> > Kalle
>>>>>> >
>>>>>> >
>>>>>> > On Thu, Sep 10, 2009 at 2:55 PM, Bruno Santos <bi...@gmail.com>
>>>>>> wrote:
>>>>>> >> Good evening,
>>>>>> >>
>>>>>> >> I have a form using a zone and i have @CommitAfter on the
>>>>>> >> onSubmitFromEntityForm()
>>>>>> >>
>>>>>> >> <t:form t:id="entityForm" zone="entityZone">
>>>>>> >> <input type="text" t:type="textfield" t:id="name"
>>>>>> >> t:value="entity.name" />
>>>>>> >> </t:form>
>>>>>> >>
>>>>>> >> @CommitAfter
>>>>>> >> Object onSubmitFromEntityForm() {
>>>>>> >> ....
>>>>>> >> try {
>>>>>> >> entityDao.persist(entity);
>>>>>> >> } catch (exception ex) {
>>>>>> >> // handle exception
>>>>>> >> }
>>>>>> >> }
>>>>>> >>
>>>>>> >> altough i'm handling the exception the @CommitAfter creates a new
>>>>>> >> exception since it tries to commit something that's not in transaction
>>>>>> >> due to catched exception.
>>>>>> >>
>>>>>> >> How to deal with this? Is there a way to avoid the @CommitAfter to
>>>>>> >> execute ... a handler i can use? I think i can remove the @CommitAfter
>>>>>> >> but don't believe this should be first option.
>>>>>> >>
>>>>>> >> ---------------------------------------------------------------------
>>>>>> >> 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
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>
>>
>
> ---------------------------------------------------------------------
> 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: Exception handling after violation of unique constraint
Posted by Kalle Korhonen <ka...@gmail.com>.
Yes, but the problem originates from this:
if (entity.getId().longValue() == 0l) {
league.setId(null);
}
You can't make that league object a new entity just by nullifying it's
id. Try creating a new league if you need to. Later on, since the
saveOrUpdate failed, the null id causes the problem in
DefaultHibernateDAO because that object is already Hibernate's
session.
Kalle
On Sat, Sep 12, 2009 at 8:47 AM, Bruno Santos <bi...@gmail.com> wrote:
> The question is i'm not trying to flush anything, i do (through DAO)
> session.saveOrUpdate, catch the exception and the only thing i do
> besides registering the error on the form is returning this (the page
> i'm at) wich causes (i guess) tapestry to query database to fill data
> for selectmodels. And, at this point i think tapestry uses the same
> session it used for the saveorupdate and "list" trys to flush if
> there's "dirty data".
>
> On Sat, Sep 12, 2009 at 3:02 AM, Kalle Korhonen
> <ka...@gmail.com> wrote:
>> I'm using the plain hibernate Session (shadow) and the pattern works
>> great for me. But I think your problem is actually in "(don't flush
>> the
>> Session after an exception occurs)". You are doing something odd since
>> you need to nullify the id. For a new object, the id should normally
>> be null. Tapestry is already thinking it's a previously persisted
>> entity.
>>
>> Kalle
>>
>>
>> On Fri, Sep 11, 2009 at 2:30 PM, Bruno Santos <bi...@gmail.com> wrote:
>>> Hello,
>>>
>>> Well, the reason should be that with persist in validate() i validate
>>> that the entity that's inserted doesn't conflict with any database
>>> constraint like in this case and the onsucess isn't fired wich in the
>>> case a constraint is violated it doesn't seem to make sense.
>>>
>>> Anyway, even if i use the code on the onSucess method it comes down to
>>> the same issue, the exception is thrown whenever i try to do any
>>> operation that requires hibernate (problem should be in
>>> hibernatesessionmanager, not being "clean").
>>>
>>> One way i guess it could solve the problem is discarding the current
>>> hibernatesessionmanager, invalidate it somehow, but i don't know if
>>> that's possible.
>>>
>>> Thanks
>>>
>>> On Fri, Sep 11, 2009 at 10:15 PM, Sven Homburg <ho...@googlemail.com> wrote:
>>>> what is your reason, that you want to persist the enity
>>>> in the validation event?
>>>>
>>>> i think its more clear to persist it in the onSuccess event method
>>>>
>>>> with regards
>>>> Sven Homburg
>>>> Founder of the Chenille Kit Project
>>>> http://www.chenillekit.org
>>>>
>>>>
>>>>
>>>>
>>>> 2009/9/11 Bruno Santos <bi...@gmail.com>
>>>>
>>>>> Thanks for your answer, i learned a bit more of tapestry.
>>>>>
>>>>> Now i have one more problem, not exactly related but in the same area.
>>>>>
>>>>> I have
>>>>>
>>>>> void onValidateForm() {
>>>>> if (entity.getId().longValue() == 0l) {
>>>>> league.setId(null);
>>>>> }
>>>>>
>>>>> System.out.println("OnValidateForm");
>>>>> try {
>>>>> _entityDAO.persist(entity);
>>>>> } catch (RuntimeException ex) {
>>>>> leagueForm.recordError("error"); // EXCEPTION IS
>>>>> THROWN - THE TEST
>>>>> I'M DOING HITS THE UNIQUE CONSTRAINT
>>>>> }
>>>>>
>>>>> }
>>>>>
>>>>> void onFailure() {
>>>>> _entityDAO.abort();
>>>>> System.out.println("onFailure");
>>>>> }
>>>>>
>>>>> And this is working except it doesn't refresh the form with the errors
>>>>> i added on the onValidate
>>>>>
>>>>> When i use:
>>>>>
>>>>> Object onFailure() {
>>>>> _entityDAO.abort();
>>>>> System.out.println("onFailure");
>>>>> return this;
>>>>> }
>>>>>
>>>>> The following exception is thrown:
>>>>>
>>>>> Caused by: org.apache.tapestry5.ioc.internal.util.TapestryException:
>>>>> null id in pt.hi.asianconnect.entities.League entry (don't flush the
>>>>> Session after an exception occurs) [at
>>>>> classpath:pt/hi/asianconnect/components/generated/CreateUpdateLeague.tml,
>>>>> line 12]
>>>>> at
>>>>> org.apache.tapestry5.internal.bindings.PropBinding.get(PropBinding.java:62)
>>>>> at
>>>>> org.apache.tapestry5.internal.structure.InternalComponentResourcesImpl$1.read(InternalComponentResourcesImpl.java:510)
>>>>> ... 119 more
>>>>> Caused by: org.hibernate.AssertionFailure: null id in
>>>>> pt.hi.asianconnect.entities.League entry (don't flush the Session
>>>>> after an exception occurs)
>>>>> at
>>>>> org.hibernate.event.def.DefaultFlushEntityEventListener.checkId(DefaultFlushEntityEventListener.java:78)
>>>>> at
>>>>> org.hibernate.event.def.DefaultFlushEntityEventListener.getValues(DefaultFlushEntityEventListener.java:187)
>>>>> at
>>>>> org.hibernate.event.def.DefaultFlushEntityEventListener.onFlushEntity(DefaultFlushEntityEventListener.java:143)
>>>>> at
>>>>> org.hibernate.event.def.AbstractFlushingEventListener.flushEntities(AbstractFlushingEventListener.java:219)
>>>>> at
>>>>> org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:99)
>>>>> at
>>>>> org.hibernate.event.def.DefaultAutoFlushEventListener.onAutoFlush(DefaultAutoFlushEventListener.java:58)
>>>>> at
>>>>> org.hibernate.impl.SessionImpl.autoFlushIfRequired(SessionImpl.java:996)
>>>>> at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1589)
>>>>> at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:306)
>>>>> at DefaultHibernateDAO.findByCriteria(DefaultHibernateDAO.java:104)
>>>>>
>>>>>
>>>>> The abort method from DAO was an experiment of mine wich calls
>>>>> hibernatesessionmanager.abort(). From what i understand, what happens
>>>>> is when the page is to be renderered, the hibernatesessionmanager
>>>>> that's used has "dirty" data that's why it uses
>>>>> SessionImpl.autoFlushIfRequired when i'm fetching data to refill the
>>>>> page, hence my experiment on calling the abort from
>>>>> hibernatesessionmanger, still this doesn't do it and i don't know how
>>>>> to "clean" data from the sessionmanager.
>>>>>
>>>>> Ideas anyone?
>>>>>
>>>>> One importante note, the test i'm doing implies that the my method
>>>>> that saveOrUpdate the entity is "hitting" a unique constraint
>>>>>
>>>>> On Thu, Sep 10, 2009 at 11:20 PM, Kalle Korhonen
>>>>> <ka...@gmail.com> wrote:
>>>>> > You should instead try storing it onValidate. If it fails, you should
>>>>> > record an error and if it succeeds you should commit only in onSuccess
>>>>> > (but the method body can be otherwise empty).
>>>>> >
>>>>> > Kalle
>>>>> >
>>>>> >
>>>>> > On Thu, Sep 10, 2009 at 2:55 PM, Bruno Santos <bi...@gmail.com>
>>>>> wrote:
>>>>> >> Good evening,
>>>>> >>
>>>>> >> I have a form using a zone and i have @CommitAfter on the
>>>>> >> onSubmitFromEntityForm()
>>>>> >>
>>>>> >> <t:form t:id="entityForm" zone="entityZone">
>>>>> >> <input type="text" t:type="textfield" t:id="name"
>>>>> >> t:value="entity.name" />
>>>>> >> </t:form>
>>>>> >>
>>>>> >> @CommitAfter
>>>>> >> Object onSubmitFromEntityForm() {
>>>>> >> ....
>>>>> >> try {
>>>>> >> entityDao.persist(entity);
>>>>> >> } catch (exception ex) {
>>>>> >> // handle exception
>>>>> >> }
>>>>> >> }
>>>>> >>
>>>>> >> altough i'm handling the exception the @CommitAfter creates a new
>>>>> >> exception since it tries to commit something that's not in transaction
>>>>> >> due to catched exception.
>>>>> >>
>>>>> >> How to deal with this? Is there a way to avoid the @CommitAfter to
>>>>> >> execute ... a handler i can use? I think i can remove the @CommitAfter
>>>>> >> but don't believe this should be first option.
>>>>> >>
>>>>> >> ---------------------------------------------------------------------
>>>>> >> 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
>>>>>
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Exception handling after violation of unique constraint
Posted by Bruno Santos <bi...@gmail.com>.
The question is i'm not trying to flush anything, i do (through DAO)
session.saveOrUpdate, catch the exception and the only thing i do
besides registering the error on the form is returning this (the page
i'm at) wich causes (i guess) tapestry to query database to fill data
for selectmodels. And, at this point i think tapestry uses the same
session it used for the saveorupdate and "list" trys to flush if
there's "dirty data".
On Sat, Sep 12, 2009 at 3:02 AM, Kalle Korhonen
<ka...@gmail.com> wrote:
> I'm using the plain hibernate Session (shadow) and the pattern works
> great for me. But I think your problem is actually in "(don't flush
> the
> Session after an exception occurs)". You are doing something odd since
> you need to nullify the id. For a new object, the id should normally
> be null. Tapestry is already thinking it's a previously persisted
> entity.
>
> Kalle
>
>
> On Fri, Sep 11, 2009 at 2:30 PM, Bruno Santos <bi...@gmail.com> wrote:
>> Hello,
>>
>> Well, the reason should be that with persist in validate() i validate
>> that the entity that's inserted doesn't conflict with any database
>> constraint like in this case and the onsucess isn't fired wich in the
>> case a constraint is violated it doesn't seem to make sense.
>>
>> Anyway, even if i use the code on the onSucess method it comes down to
>> the same issue, the exception is thrown whenever i try to do any
>> operation that requires hibernate (problem should be in
>> hibernatesessionmanager, not being "clean").
>>
>> One way i guess it could solve the problem is discarding the current
>> hibernatesessionmanager, invalidate it somehow, but i don't know if
>> that's possible.
>>
>> Thanks
>>
>> On Fri, Sep 11, 2009 at 10:15 PM, Sven Homburg <ho...@googlemail.com> wrote:
>>> what is your reason, that you want to persist the enity
>>> in the validation event?
>>>
>>> i think its more clear to persist it in the onSuccess event method
>>>
>>> with regards
>>> Sven Homburg
>>> Founder of the Chenille Kit Project
>>> http://www.chenillekit.org
>>>
>>>
>>>
>>>
>>> 2009/9/11 Bruno Santos <bi...@gmail.com>
>>>
>>>> Thanks for your answer, i learned a bit more of tapestry.
>>>>
>>>> Now i have one more problem, not exactly related but in the same area.
>>>>
>>>> I have
>>>>
>>>> void onValidateForm() {
>>>> if (entity.getId().longValue() == 0l) {
>>>> league.setId(null);
>>>> }
>>>>
>>>> System.out.println("OnValidateForm");
>>>> try {
>>>> _entityDAO.persist(entity);
>>>> } catch (RuntimeException ex) {
>>>> leagueForm.recordError("error"); // EXCEPTION IS
>>>> THROWN - THE TEST
>>>> I'M DOING HITS THE UNIQUE CONSTRAINT
>>>> }
>>>>
>>>> }
>>>>
>>>> void onFailure() {
>>>> _entityDAO.abort();
>>>> System.out.println("onFailure");
>>>> }
>>>>
>>>> And this is working except it doesn't refresh the form with the errors
>>>> i added on the onValidate
>>>>
>>>> When i use:
>>>>
>>>> Object onFailure() {
>>>> _entityDAO.abort();
>>>> System.out.println("onFailure");
>>>> return this;
>>>> }
>>>>
>>>> The following exception is thrown:
>>>>
>>>> Caused by: org.apache.tapestry5.ioc.internal.util.TapestryException:
>>>> null id in pt.hi.asianconnect.entities.League entry (don't flush the
>>>> Session after an exception occurs) [at
>>>> classpath:pt/hi/asianconnect/components/generated/CreateUpdateLeague.tml,
>>>> line 12]
>>>> at
>>>> org.apache.tapestry5.internal.bindings.PropBinding.get(PropBinding.java:62)
>>>> at
>>>> org.apache.tapestry5.internal.structure.InternalComponentResourcesImpl$1.read(InternalComponentResourcesImpl.java:510)
>>>> ... 119 more
>>>> Caused by: org.hibernate.AssertionFailure: null id in
>>>> pt.hi.asianconnect.entities.League entry (don't flush the Session
>>>> after an exception occurs)
>>>> at
>>>> org.hibernate.event.def.DefaultFlushEntityEventListener.checkId(DefaultFlushEntityEventListener.java:78)
>>>> at
>>>> org.hibernate.event.def.DefaultFlushEntityEventListener.getValues(DefaultFlushEntityEventListener.java:187)
>>>> at
>>>> org.hibernate.event.def.DefaultFlushEntityEventListener.onFlushEntity(DefaultFlushEntityEventListener.java:143)
>>>> at
>>>> org.hibernate.event.def.AbstractFlushingEventListener.flushEntities(AbstractFlushingEventListener.java:219)
>>>> at
>>>> org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:99)
>>>> at
>>>> org.hibernate.event.def.DefaultAutoFlushEventListener.onAutoFlush(DefaultAutoFlushEventListener.java:58)
>>>> at
>>>> org.hibernate.impl.SessionImpl.autoFlushIfRequired(SessionImpl.java:996)
>>>> at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1589)
>>>> at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:306)
>>>> at DefaultHibernateDAO.findByCriteria(DefaultHibernateDAO.java:104)
>>>>
>>>>
>>>> The abort method from DAO was an experiment of mine wich calls
>>>> hibernatesessionmanager.abort(). From what i understand, what happens
>>>> is when the page is to be renderered, the hibernatesessionmanager
>>>> that's used has "dirty" data that's why it uses
>>>> SessionImpl.autoFlushIfRequired when i'm fetching data to refill the
>>>> page, hence my experiment on calling the abort from
>>>> hibernatesessionmanger, still this doesn't do it and i don't know how
>>>> to "clean" data from the sessionmanager.
>>>>
>>>> Ideas anyone?
>>>>
>>>> One importante note, the test i'm doing implies that the my method
>>>> that saveOrUpdate the entity is "hitting" a unique constraint
>>>>
>>>> On Thu, Sep 10, 2009 at 11:20 PM, Kalle Korhonen
>>>> <ka...@gmail.com> wrote:
>>>> > You should instead try storing it onValidate. If it fails, you should
>>>> > record an error and if it succeeds you should commit only in onSuccess
>>>> > (but the method body can be otherwise empty).
>>>> >
>>>> > Kalle
>>>> >
>>>> >
>>>> > On Thu, Sep 10, 2009 at 2:55 PM, Bruno Santos <bi...@gmail.com>
>>>> wrote:
>>>> >> Good evening,
>>>> >>
>>>> >> I have a form using a zone and i have @CommitAfter on the
>>>> >> onSubmitFromEntityForm()
>>>> >>
>>>> >> <t:form t:id="entityForm" zone="entityZone">
>>>> >> <input type="text" t:type="textfield" t:id="name"
>>>> >> t:value="entity.name" />
>>>> >> </t:form>
>>>> >>
>>>> >> @CommitAfter
>>>> >> Object onSubmitFromEntityForm() {
>>>> >> ....
>>>> >> try {
>>>> >> entityDao.persist(entity);
>>>> >> } catch (exception ex) {
>>>> >> // handle exception
>>>> >> }
>>>> >> }
>>>> >>
>>>> >> altough i'm handling the exception the @CommitAfter creates a new
>>>> >> exception since it tries to commit something that's not in transaction
>>>> >> due to catched exception.
>>>> >>
>>>> >> How to deal with this? Is there a way to avoid the @CommitAfter to
>>>> >> execute ... a handler i can use? I think i can remove the @CommitAfter
>>>> >> but don't believe this should be first option.
>>>> >>
>>>> >> ---------------------------------------------------------------------
>>>> >> 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
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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: Exception handling after violation of unique constraint
Posted by Kalle Korhonen <ka...@gmail.com>.
I'm using the plain hibernate Session (shadow) and the pattern works
great for me. But I think your problem is actually in "(don't flush
the
Session after an exception occurs)". You are doing something odd since
you need to nullify the id. For a new object, the id should normally
be null. Tapestry is already thinking it's a previously persisted
entity.
Kalle
On Fri, Sep 11, 2009 at 2:30 PM, Bruno Santos <bi...@gmail.com> wrote:
> Hello,
>
> Well, the reason should be that with persist in validate() i validate
> that the entity that's inserted doesn't conflict with any database
> constraint like in this case and the onsucess isn't fired wich in the
> case a constraint is violated it doesn't seem to make sense.
>
> Anyway, even if i use the code on the onSucess method it comes down to
> the same issue, the exception is thrown whenever i try to do any
> operation that requires hibernate (problem should be in
> hibernatesessionmanager, not being "clean").
>
> One way i guess it could solve the problem is discarding the current
> hibernatesessionmanager, invalidate it somehow, but i don't know if
> that's possible.
>
> Thanks
>
> On Fri, Sep 11, 2009 at 10:15 PM, Sven Homburg <ho...@googlemail.com> wrote:
>> what is your reason, that you want to persist the enity
>> in the validation event?
>>
>> i think its more clear to persist it in the onSuccess event method
>>
>> with regards
>> Sven Homburg
>> Founder of the Chenille Kit Project
>> http://www.chenillekit.org
>>
>>
>>
>>
>> 2009/9/11 Bruno Santos <bi...@gmail.com>
>>
>>> Thanks for your answer, i learned a bit more of tapestry.
>>>
>>> Now i have one more problem, not exactly related but in the same area.
>>>
>>> I have
>>>
>>> void onValidateForm() {
>>> if (entity.getId().longValue() == 0l) {
>>> league.setId(null);
>>> }
>>>
>>> System.out.println("OnValidateForm");
>>> try {
>>> _entityDAO.persist(entity);
>>> } catch (RuntimeException ex) {
>>> leagueForm.recordError("error"); // EXCEPTION IS
>>> THROWN - THE TEST
>>> I'M DOING HITS THE UNIQUE CONSTRAINT
>>> }
>>>
>>> }
>>>
>>> void onFailure() {
>>> _entityDAO.abort();
>>> System.out.println("onFailure");
>>> }
>>>
>>> And this is working except it doesn't refresh the form with the errors
>>> i added on the onValidate
>>>
>>> When i use:
>>>
>>> Object onFailure() {
>>> _entityDAO.abort();
>>> System.out.println("onFailure");
>>> return this;
>>> }
>>>
>>> The following exception is thrown:
>>>
>>> Caused by: org.apache.tapestry5.ioc.internal.util.TapestryException:
>>> null id in pt.hi.asianconnect.entities.League entry (don't flush the
>>> Session after an exception occurs) [at
>>> classpath:pt/hi/asianconnect/components/generated/CreateUpdateLeague.tml,
>>> line 12]
>>> at
>>> org.apache.tapestry5.internal.bindings.PropBinding.get(PropBinding.java:62)
>>> at
>>> org.apache.tapestry5.internal.structure.InternalComponentResourcesImpl$1.read(InternalComponentResourcesImpl.java:510)
>>> ... 119 more
>>> Caused by: org.hibernate.AssertionFailure: null id in
>>> pt.hi.asianconnect.entities.League entry (don't flush the Session
>>> after an exception occurs)
>>> at
>>> org.hibernate.event.def.DefaultFlushEntityEventListener.checkId(DefaultFlushEntityEventListener.java:78)
>>> at
>>> org.hibernate.event.def.DefaultFlushEntityEventListener.getValues(DefaultFlushEntityEventListener.java:187)
>>> at
>>> org.hibernate.event.def.DefaultFlushEntityEventListener.onFlushEntity(DefaultFlushEntityEventListener.java:143)
>>> at
>>> org.hibernate.event.def.AbstractFlushingEventListener.flushEntities(AbstractFlushingEventListener.java:219)
>>> at
>>> org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:99)
>>> at
>>> org.hibernate.event.def.DefaultAutoFlushEventListener.onAutoFlush(DefaultAutoFlushEventListener.java:58)
>>> at
>>> org.hibernate.impl.SessionImpl.autoFlushIfRequired(SessionImpl.java:996)
>>> at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1589)
>>> at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:306)
>>> at DefaultHibernateDAO.findByCriteria(DefaultHibernateDAO.java:104)
>>>
>>>
>>> The abort method from DAO was an experiment of mine wich calls
>>> hibernatesessionmanager.abort(). From what i understand, what happens
>>> is when the page is to be renderered, the hibernatesessionmanager
>>> that's used has "dirty" data that's why it uses
>>> SessionImpl.autoFlushIfRequired when i'm fetching data to refill the
>>> page, hence my experiment on calling the abort from
>>> hibernatesessionmanger, still this doesn't do it and i don't know how
>>> to "clean" data from the sessionmanager.
>>>
>>> Ideas anyone?
>>>
>>> One importante note, the test i'm doing implies that the my method
>>> that saveOrUpdate the entity is "hitting" a unique constraint
>>>
>>> On Thu, Sep 10, 2009 at 11:20 PM, Kalle Korhonen
>>> <ka...@gmail.com> wrote:
>>> > You should instead try storing it onValidate. If it fails, you should
>>> > record an error and if it succeeds you should commit only in onSuccess
>>> > (but the method body can be otherwise empty).
>>> >
>>> > Kalle
>>> >
>>> >
>>> > On Thu, Sep 10, 2009 at 2:55 PM, Bruno Santos <bi...@gmail.com>
>>> wrote:
>>> >> Good evening,
>>> >>
>>> >> I have a form using a zone and i have @CommitAfter on the
>>> >> onSubmitFromEntityForm()
>>> >>
>>> >> <t:form t:id="entityForm" zone="entityZone">
>>> >> <input type="text" t:type="textfield" t:id="name"
>>> >> t:value="entity.name" />
>>> >> </t:form>
>>> >>
>>> >> @CommitAfter
>>> >> Object onSubmitFromEntityForm() {
>>> >> ....
>>> >> try {
>>> >> entityDao.persist(entity);
>>> >> } catch (exception ex) {
>>> >> // handle exception
>>> >> }
>>> >> }
>>> >>
>>> >> altough i'm handling the exception the @CommitAfter creates a new
>>> >> exception since it tries to commit something that's not in transaction
>>> >> due to catched exception.
>>> >>
>>> >> How to deal with this? Is there a way to avoid the @CommitAfter to
>>> >> execute ... a handler i can use? I think i can remove the @CommitAfter
>>> >> but don't believe this should be first option.
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> 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
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> 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: Exception handling after violation of unique constraint
Posted by Kalle Korhonen <ka...@gmail.com>.
On Fri, Sep 11, 2009 at 7:26 PM, Thiago H. de Paula Figueiredo
<th...@gmail.com> wrote:
> Em Fri, 11 Sep 2009 23:11:59 -0300, Kalle Korhonen
> <ka...@gmail.com> escreveu:
> I think onValidate() is for validation, the data store should only be
> changed (or attepted to be changed) when validation succeeds and controller
> classes (business rules tier) should deal with transactions, not
> Tapestry-related code (nor any UI code). I write code following the
> three-tiers architecture and the separation of concerns philosphy strictly.
Ok I see where you are coming from. I'm not a purist - I typically do
the least amount of work up front and try to avoid the extra layer of
indirection whenever possible. Tapestry offers a fairly clean
separation of logic and UI concerns straight-up and unless I need a
separate business layer (say if I had a completely different interface
to the same data), I don't add it in automatically. But I totally
understand your point of view - it's more in line of JEE/EJB
architecture and offers its own benefits.
Kalle
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Exception handling after violation of unique constraint
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Fri, 11 Sep 2009 23:11:59 -0300, Kalle Korhonen
<ka...@gmail.com> escreveu:
> Interesting - I happen to think it's a great pattern to follow. You
> try to save and then roll back if it didn't work out - that's what the
> transaction management is for and Tapestry gives you a very nice way
> to accomplish this easily.
I think onValidate() is for validation, the data store should only be
changed (or attepted to be changed) when validation succeeds and
controller classes (business rules tier) should deal with transactions,
not Tapestry-related code (nor any UI code). I write code following the
three-tiers architecture and the separation of concerns philosphy strictly.
> If you only save in onSuccess you have to
> decide yourself whether you want to commit or abort,especially if
> multiple objects are involved and can't easily communicate back to the
> user what the error was (if he was trying to submit a form). How would
> you do this?
My approach is to write code to check any consistence error before sending
data to the store. This way, the only errors left are not recoverable (not
related to business logic)and a generic error message is shown. I love
checks buit int the database, but I don't use them to do validation, just
to make sure no inconsistent data is written.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Exception handling after violation of unique constraint
Posted by Kalle Korhonen <ka...@gmail.com>.
On Fri, Sep 11, 2009 at 3:05 PM, Thiago H. de Paula Figueiredo
<th...@gmail.com> wrote:
> Em Fri, 11 Sep 2009 18:30:34 -0300, Bruno Santos <bi...@gmail.com>
> IMHO, you have to write code to do that (query the database if needed)
Well that doesn't do anything else except merely lowers the probability.
> intead of sending data to the database and expect it to raise erros to you.
> IMHO, you should never write to your datastore in onValidate().
Interesting - I happen to think it's a great pattern to follow. You
try to save and then roll back if it didn't work out - that's what the
transaction management is for and Tapestry gives you a very nice way
to accomplish this easily. If you only save in onSuccess you have to
decide yourself whether you want to commit or abort, especially if
multiple objects are involved and can't easily communicate back to the
user what the error was (if he was trying to submit a form). How would
you do this?
Kalle
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Exception handling after violation of unique constraint
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Fri, 11 Sep 2009 18:30:34 -0300, Bruno Santos <bi...@gmail.com>
escreveu:
> Hello,
Hi!
> Well, the reason should be that with persist in validate() i validate
> that the entity that's inserted doesn't conflict with any database
> constraint like in this case and the onsucess isn't fired wich in the
> case a constraint is violated it doesn't seem to make sense.
IMHO, you have to write code to do that (query the database if needed)
intead of sending data to the database and expect it to raise erros to you.
IMHO, you should never write to your datastore in onValidate().
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Fwd: Exception handling after violation of unique constraint
Posted by Bruno Santos <bi...@gmail.com>.
Hit wrong button i guess, sent message only to Sven. Sorry
---------- Forwarded message ----------
From: Bruno Santos
Date: Fri, Sep 11, 2009 at 11:19 PM
Subject: Re: Exception handling after violation of unique constraint
First i like to thank you (both) for your patience and help.
Well, not the solution i was looking for but i guess it solves some
issues, totally agree with it and certainly will use it.
However, It doesn't solved non checked exceptions hibernate might
throw, like constraints that are forgotten, or other DML issues. And,
production wise, what happens is user just staring to the page waiting
for it to do something, giving some feedback and nothing happens.
Isn't there a "catch all exception and present user some feedback
option"? Or an option like "don't use this hibernatesessionmanager
because it's invalid option"?
Regards
On Fri, Sep 11, 2009 at 10:58 PM, Sven Homburg <ho...@googlemail.com> wrote:
> i think a good way for prevent doublettes
> in you database is by using an Example-Query:
> http://docs.jboss.org/hibernate/stable/core/reference/en/html/querycriteria.html#querycriteria-examples
>
>
> with regards
> Sven Homburg
> Founder of the Chenille Kit Project
> http://www.chenillekit.org
>
>
>
>
> 2009/9/11 Bruno Santos <bi...@gmail.com>
>>
>> Hello,
>>
>> Well, the reason should be that with persist in validate() i validate
>> that the entity that's inserted doesn't conflict with any database
>> constraint like in this case and the onsucess isn't fired wich in the
>> case a constraint is violated it doesn't seem to make sense.
>>
>> Anyway, even if i use the code on the onSucess method it comes down to
>> the same issue, the exception is thrown whenever i try to do any
>> operation that requires hibernate (problem should be in
>> hibernatesessionmanager, not being "clean").
>>
>> One way i guess it could solve the problem is discarding the current
>> hibernatesessionmanager, invalidate it somehow, but i don't know if
>> that's possible.
>>
>> Thanks
>>
>> On Fri, Sep 11, 2009 at 10:15 PM, Sven Homburg <ho...@googlemail.com>
>> wrote:
>> > what is your reason, that you want to persist the enity
>> > in the validation event?
>> >
>> > i think its more clear to persist it in the onSuccess event method
>> >
>> > with regards
>> > Sven Homburg
>> > Founder of the Chenille Kit Project
>> > http://www.chenillekit.org
>> >
>> >
>> >
>> >
>> > 2009/9/11 Bruno Santos <bi...@gmail.com>
>> >
>> >> Thanks for your answer, i learned a bit more of tapestry.
>> >>
>> >> Now i have one more problem, not exactly related but in the same area.
>> >>
>> >> I have
>> >>
>> >> void onValidateForm() {
>> >> if (entity.getId().longValue() == 0l) {
>> >> league.setId(null);
>> >> }
>> >>
>> >> System.out.println("OnValidateForm");
>> >> try {
>> >> _entityDAO.persist(entity);
>> >> } catch (RuntimeException ex) {
>> >> leagueForm.recordError("error"); // EXCEPTION IS
>> >> THROWN - THE TEST
>> >> I'M DOING HITS THE UNIQUE CONSTRAINT
>> >> }
>> >>
>> >> }
>> >>
>> >> void onFailure() {
>> >> _entityDAO.abort();
>> >> System.out.println("onFailure");
>> >> }
>> >>
>> >> And this is working except it doesn't refresh the form with the errors
>> >> i added on the onValidate
>> >>
>> >> When i use:
>> >>
>> >> Object onFailure() {
>> >> _entityDAO.abort();
>> >> System.out.println("onFailure");
>> >> return this;
>> >> }
>> >>
>> >> The following exception is thrown:
>> >>
>> >> Caused by: org.apache.tapestry5.ioc.internal.util.TapestryException:
>> >> null id in pt.hi.asianconnect.entities.League entry (don't flush the
>> >> Session after an exception occurs) [at
>> >>
>> >> classpath:pt/hi/asianconnect/components/generated/CreateUpdateLeague.tml,
>> >> line 12]
>> >> at
>> >>
>> >> org.apache.tapestry5.internal.bindings.PropBinding.get(PropBinding.java:62)
>> >> at
>> >>
>> >> org.apache.tapestry5.internal.structure.InternalComponentResourcesImpl$1.read(InternalComponentResourcesImpl.java:510)
>> >> ... 119 more
>> >> Caused by: org.hibernate.AssertionFailure: null id in
>> >> pt.hi.asianconnect.entities.League entry (don't flush the Session
>> >> after an exception occurs)
>> >> at
>> >>
>> >> org.hibernate.event.def.DefaultFlushEntityEventListener.checkId(DefaultFlushEntityEventListener.java:78)
>> >> at
>> >>
>> >> org.hibernate.event.def.DefaultFlushEntityEventListener.getValues(DefaultFlushEntityEventListener.java:187)
>> >> at
>> >>
>> >> org.hibernate.event.def.DefaultFlushEntityEventListener.onFlushEntity(DefaultFlushEntityEventListener.java:143)
>> >> at
>> >>
>> >> org.hibernate.event.def.AbstractFlushingEventListener.flushEntities(AbstractFlushingEventListener.java:219)
>> >> at
>> >>
>> >> org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:99)
>> >> at
>> >>
>> >> org.hibernate.event.def.DefaultAutoFlushEventListener.onAutoFlush(DefaultAutoFlushEventListener.java:58)
>> >> at
>> >>
>> >> org.hibernate.impl.SessionImpl.autoFlushIfRequired(SessionImpl.java:996)
>> >> at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1589)
>> >> at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:306)
>> >> at
>> >> DefaultHibernateDAO.findByCriteria(DefaultHibernateDAO.java:104)
>> >>
>> >>
>> >> The abort method from DAO was an experiment of mine wich calls
>> >> hibernatesessionmanager.abort(). From what i understand, what happens
>> >> is when the page is to be renderered, the hibernatesessionmanager
>> >> that's used has "dirty" data that's why it uses
>> >> SessionImpl.autoFlushIfRequired when i'm fetching data to refill the
>> >> page, hence my experiment on calling the abort from
>> >> hibernatesessionmanger, still this doesn't do it and i don't know how
>> >> to "clean" data from the sessionmanager.
>> >>
>> >> Ideas anyone?
>> >>
>> >> One importante note, the test i'm doing implies that the my method
>> >> that saveOrUpdate the entity is "hitting" a unique constraint
>> >>
>> >> On Thu, Sep 10, 2009 at 11:20 PM, Kalle Korhonen
>> >> <ka...@gmail.com> wrote:
>> >> > You should instead try storing it onValidate. If it fails, you should
>> >> > record an error and if it succeeds you should commit only in
>> >> > onSuccess
>> >> > (but the method body can be otherwise empty).
>> >> >
>> >> > Kalle
>> >> >
>> >> >
>> >> > On Thu, Sep 10, 2009 at 2:55 PM, Bruno Santos <bi...@gmail.com>
>> >> wrote:
>> >> >> Good evening,
>> >> >>
>> >> >> I have a form using a zone and i have @CommitAfter on the
>> >> >> onSubmitFromEntityForm()
>> >> >>
>> >> >> <t:form t:id="entityForm" zone="entityZone">
>> >> >> <input type="text" t:type="textfield" t:id="name"
>> >> >> t:value="entity.name" />
>> >> >> </t:form>
>> >> >>
>> >> >> @CommitAfter
>> >> >> Object onSubmitFromEntityForm() {
>> >> >> ....
>> >> >> try {
>> >> >> entityDao.persist(entity);
>> >> >> } catch (exception ex) {
>> >> >> // handle exception
>> >> >> }
>> >> >> }
>> >> >>
>> >> >> altough i'm handling the exception the @CommitAfter creates a new
>> >> >> exception since it tries to commit something that's not in
>> >> >> transaction
>> >> >> due to catched exception.
>> >> >>
>> >> >> How to deal with this? Is there a way to avoid the @CommitAfter to
>> >> >> execute ... a handler i can use? I think i can remove the
>> >> >> @CommitAfter
>> >> >> but don't believe this should be first option.
>> >> >>
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> 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
>> >>
>> >>
>> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Exception handling after violation of unique constraint
Posted by Bruno Santos <bi...@gmail.com>.
Hello,
Well, the reason should be that with persist in validate() i validate
that the entity that's inserted doesn't conflict with any database
constraint like in this case and the onsucess isn't fired wich in the
case a constraint is violated it doesn't seem to make sense.
Anyway, even if i use the code on the onSucess method it comes down to
the same issue, the exception is thrown whenever i try to do any
operation that requires hibernate (problem should be in
hibernatesessionmanager, not being "clean").
One way i guess it could solve the problem is discarding the current
hibernatesessionmanager, invalidate it somehow, but i don't know if
that's possible.
Thanks
On Fri, Sep 11, 2009 at 10:15 PM, Sven Homburg <ho...@googlemail.com> wrote:
> what is your reason, that you want to persist the enity
> in the validation event?
>
> i think its more clear to persist it in the onSuccess event method
>
> with regards
> Sven Homburg
> Founder of the Chenille Kit Project
> http://www.chenillekit.org
>
>
>
>
> 2009/9/11 Bruno Santos <bi...@gmail.com>
>
>> Thanks for your answer, i learned a bit more of tapestry.
>>
>> Now i have one more problem, not exactly related but in the same area.
>>
>> I have
>>
>> void onValidateForm() {
>> if (entity.getId().longValue() == 0l) {
>> league.setId(null);
>> }
>>
>> System.out.println("OnValidateForm");
>> try {
>> _entityDAO.persist(entity);
>> } catch (RuntimeException ex) {
>> leagueForm.recordError("error"); // EXCEPTION IS
>> THROWN - THE TEST
>> I'M DOING HITS THE UNIQUE CONSTRAINT
>> }
>>
>> }
>>
>> void onFailure() {
>> _entityDAO.abort();
>> System.out.println("onFailure");
>> }
>>
>> And this is working except it doesn't refresh the form with the errors
>> i added on the onValidate
>>
>> When i use:
>>
>> Object onFailure() {
>> _entityDAO.abort();
>> System.out.println("onFailure");
>> return this;
>> }
>>
>> The following exception is thrown:
>>
>> Caused by: org.apache.tapestry5.ioc.internal.util.TapestryException:
>> null id in pt.hi.asianconnect.entities.League entry (don't flush the
>> Session after an exception occurs) [at
>> classpath:pt/hi/asianconnect/components/generated/CreateUpdateLeague.tml,
>> line 12]
>> at
>> org.apache.tapestry5.internal.bindings.PropBinding.get(PropBinding.java:62)
>> at
>> org.apache.tapestry5.internal.structure.InternalComponentResourcesImpl$1.read(InternalComponentResourcesImpl.java:510)
>> ... 119 more
>> Caused by: org.hibernate.AssertionFailure: null id in
>> pt.hi.asianconnect.entities.League entry (don't flush the Session
>> after an exception occurs)
>> at
>> org.hibernate.event.def.DefaultFlushEntityEventListener.checkId(DefaultFlushEntityEventListener.java:78)
>> at
>> org.hibernate.event.def.DefaultFlushEntityEventListener.getValues(DefaultFlushEntityEventListener.java:187)
>> at
>> org.hibernate.event.def.DefaultFlushEntityEventListener.onFlushEntity(DefaultFlushEntityEventListener.java:143)
>> at
>> org.hibernate.event.def.AbstractFlushingEventListener.flushEntities(AbstractFlushingEventListener.java:219)
>> at
>> org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:99)
>> at
>> org.hibernate.event.def.DefaultAutoFlushEventListener.onAutoFlush(DefaultAutoFlushEventListener.java:58)
>> at
>> org.hibernate.impl.SessionImpl.autoFlushIfRequired(SessionImpl.java:996)
>> at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1589)
>> at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:306)
>> at DefaultHibernateDAO.findByCriteria(DefaultHibernateDAO.java:104)
>>
>>
>> The abort method from DAO was an experiment of mine wich calls
>> hibernatesessionmanager.abort(). From what i understand, what happens
>> is when the page is to be renderered, the hibernatesessionmanager
>> that's used has "dirty" data that's why it uses
>> SessionImpl.autoFlushIfRequired when i'm fetching data to refill the
>> page, hence my experiment on calling the abort from
>> hibernatesessionmanger, still this doesn't do it and i don't know how
>> to "clean" data from the sessionmanager.
>>
>> Ideas anyone?
>>
>> One importante note, the test i'm doing implies that the my method
>> that saveOrUpdate the entity is "hitting" a unique constraint
>>
>> On Thu, Sep 10, 2009 at 11:20 PM, Kalle Korhonen
>> <ka...@gmail.com> wrote:
>> > You should instead try storing it onValidate. If it fails, you should
>> > record an error and if it succeeds you should commit only in onSuccess
>> > (but the method body can be otherwise empty).
>> >
>> > Kalle
>> >
>> >
>> > On Thu, Sep 10, 2009 at 2:55 PM, Bruno Santos <bi...@gmail.com>
>> wrote:
>> >> Good evening,
>> >>
>> >> I have a form using a zone and i have @CommitAfter on the
>> >> onSubmitFromEntityForm()
>> >>
>> >> <t:form t:id="entityForm" zone="entityZone">
>> >> <input type="text" t:type="textfield" t:id="name"
>> >> t:value="entity.name" />
>> >> </t:form>
>> >>
>> >> @CommitAfter
>> >> Object onSubmitFromEntityForm() {
>> >> ....
>> >> try {
>> >> entityDao.persist(entity);
>> >> } catch (exception ex) {
>> >> // handle exception
>> >> }
>> >> }
>> >>
>> >> altough i'm handling the exception the @CommitAfter creates a new
>> >> exception since it tries to commit something that's not in transaction
>> >> due to catched exception.
>> >>
>> >> How to deal with this? Is there a way to avoid the @CommitAfter to
>> >> execute ... a handler i can use? I think i can remove the @CommitAfter
>> >> but don't believe this should be first option.
>> >>
>> >> ---------------------------------------------------------------------
>> >> 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
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Exception handling after violation of unique constraint
Posted by Sven Homburg <ho...@googlemail.com>.
what is your reason, that you want to persist the enity
in the validation event?
i think its more clear to persist it in the onSuccess event method
with regards
Sven Homburg
Founder of the Chenille Kit Project
http://www.chenillekit.org
2009/9/11 Bruno Santos <bi...@gmail.com>
> Thanks for your answer, i learned a bit more of tapestry.
>
> Now i have one more problem, not exactly related but in the same area.
>
> I have
>
> void onValidateForm() {
> if (entity.getId().longValue() == 0l) {
> league.setId(null);
> }
>
> System.out.println("OnValidateForm");
> try {
> _entityDAO.persist(entity);
> } catch (RuntimeException ex) {
> leagueForm.recordError("error"); // EXCEPTION IS
> THROWN - THE TEST
> I'M DOING HITS THE UNIQUE CONSTRAINT
> }
>
> }
>
> void onFailure() {
> _entityDAO.abort();
> System.out.println("onFailure");
> }
>
> And this is working except it doesn't refresh the form with the errors
> i added on the onValidate
>
> When i use:
>
> Object onFailure() {
> _entityDAO.abort();
> System.out.println("onFailure");
> return this;
> }
>
> The following exception is thrown:
>
> Caused by: org.apache.tapestry5.ioc.internal.util.TapestryException:
> null id in pt.hi.asianconnect.entities.League entry (don't flush the
> Session after an exception occurs) [at
> classpath:pt/hi/asianconnect/components/generated/CreateUpdateLeague.tml,
> line 12]
> at
> org.apache.tapestry5.internal.bindings.PropBinding.get(PropBinding.java:62)
> at
> org.apache.tapestry5.internal.structure.InternalComponentResourcesImpl$1.read(InternalComponentResourcesImpl.java:510)
> ... 119 more
> Caused by: org.hibernate.AssertionFailure: null id in
> pt.hi.asianconnect.entities.League entry (don't flush the Session
> after an exception occurs)
> at
> org.hibernate.event.def.DefaultFlushEntityEventListener.checkId(DefaultFlushEntityEventListener.java:78)
> at
> org.hibernate.event.def.DefaultFlushEntityEventListener.getValues(DefaultFlushEntityEventListener.java:187)
> at
> org.hibernate.event.def.DefaultFlushEntityEventListener.onFlushEntity(DefaultFlushEntityEventListener.java:143)
> at
> org.hibernate.event.def.AbstractFlushingEventListener.flushEntities(AbstractFlushingEventListener.java:219)
> at
> org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:99)
> at
> org.hibernate.event.def.DefaultAutoFlushEventListener.onAutoFlush(DefaultAutoFlushEventListener.java:58)
> at
> org.hibernate.impl.SessionImpl.autoFlushIfRequired(SessionImpl.java:996)
> at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1589)
> at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:306)
> at DefaultHibernateDAO.findByCriteria(DefaultHibernateDAO.java:104)
>
>
> The abort method from DAO was an experiment of mine wich calls
> hibernatesessionmanager.abort(). From what i understand, what happens
> is when the page is to be renderered, the hibernatesessionmanager
> that's used has "dirty" data that's why it uses
> SessionImpl.autoFlushIfRequired when i'm fetching data to refill the
> page, hence my experiment on calling the abort from
> hibernatesessionmanger, still this doesn't do it and i don't know how
> to "clean" data from the sessionmanager.
>
> Ideas anyone?
>
> One importante note, the test i'm doing implies that the my method
> that saveOrUpdate the entity is "hitting" a unique constraint
>
> On Thu, Sep 10, 2009 at 11:20 PM, Kalle Korhonen
> <ka...@gmail.com> wrote:
> > You should instead try storing it onValidate. If it fails, you should
> > record an error and if it succeeds you should commit only in onSuccess
> > (but the method body can be otherwise empty).
> >
> > Kalle
> >
> >
> > On Thu, Sep 10, 2009 at 2:55 PM, Bruno Santos <bi...@gmail.com>
> wrote:
> >> Good evening,
> >>
> >> I have a form using a zone and i have @CommitAfter on the
> >> onSubmitFromEntityForm()
> >>
> >> <t:form t:id="entityForm" zone="entityZone">
> >> <input type="text" t:type="textfield" t:id="name"
> >> t:value="entity.name" />
> >> </t:form>
> >>
> >> @CommitAfter
> >> Object onSubmitFromEntityForm() {
> >> ....
> >> try {
> >> entityDao.persist(entity);
> >> } catch (exception ex) {
> >> // handle exception
> >> }
> >> }
> >>
> >> altough i'm handling the exception the @CommitAfter creates a new
> >> exception since it tries to commit something that's not in transaction
> >> due to catched exception.
> >>
> >> How to deal with this? Is there a way to avoid the @CommitAfter to
> >> execute ... a handler i can use? I think i can remove the @CommitAfter
> >> but don't believe this should be first option.
> >>
> >> ---------------------------------------------------------------------
> >> 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
>
>