You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by CREMONINI Daniele <Da...@ext.efsa.europa.eu> on 2010/10/08 09:27:54 UTC
Testing concurrant updates on database
Hi everybody,
My problem is I have to test a Page that should prevent lost updates via optimistic lock checking.
I resolved the problem using JPA optimistic lock and if I use two different browsers then the Page works in the desired way.
The problem comes in the test phase: to emulate two concurrent sessions I would instantiate two pages accessing to the same object (record) on the database this way having two sessions that I will call A and B.
Then on the session A I update and save (everything is expected to be correct), then on session B I update and save (an exception is expected to be thrown).
My approach might be
final WicketTester.DummyWebApplication testWebApplication1 = new WicketTester.DummyWebApplication() ...
final WicketTester.DummyWebApplication testWebApplication2 = new WicketTester.DummyWebApplication() ...
...
tester1 = new MyAppWicketTester(testWebApplication);
tester2 = new MyAppWicketTester(testWebApplication);
tester1.startPage(new ITestPageSource() ...
tester2.startPage(new ITestPageSource() ...
but as soon as run the complete set of test anything "blow up".
Do you have any suggestion?
Thanks
Daniele Cremonini
RE: Testing concurrant updates on database
Posted by CREMONINI Daniele <Da...@ext.efsa.europa.eu>.
SOLVED!
I followed your advice and added an hidden field to the Page (this is much simpler than my previous solution) but instead of using a Validator I made the service layer catch OptimisticLockingFailureException (thrown by the ORM layer) and rethrow a custom Exception.
Your advice on testing the Page using a single session works fine with the realistic assumption that the lifecycle has not any "pitfall" and I'll adopt this method.
Thanks a lot.
Good bye
Daniele Cremonini
-----Original Message-----
From: jcarman@carmanconsulting.com [mailto:jcarman@carmanconsulting.com] On Behalf Of James Carman
Sent: 11 October 2010 10:09
To: users@wicket.apache.org
Subject: Re: Testing concurrant updates on database
You're really not supposed to be monkeying with the version property
yourself. You're supposed to let the ORM provider do that. What I
would do is create a hidden field and put a validator on that. The
validator would check to make sure that the current version in the
database is the same as what you got when you read the record out
initially. You then just basically need to test that this works
properly (using mock objects for your DAOs). You can assume that the
database ORM provider's locking works property, or at least I would.
To make sure nobody turns off the optimistic locking in the future,
just add in a unit test case that validates that the optimistic
locking is turned on by checking the metadata.
On Mon, Oct 11, 2010 at 4:00 AM, CREMONINI Daniele
<Da...@ext.efsa.europa.eu> wrote:
> Thank you for your reply.
>
> I'm using Wicket 1.3.4.
>
> The optimistic locking is enabled for sure (the program has been written by me) and metadata and data confirm that things are actually functioning the way I thought.
>
> Because the Page contains a LoadableDetachableModel, every time I submit the page, Wicket reloads the object overwriting the version attribute.
> To workaround this behaviour I overridden the onBeforeRender method to save the version as soon as I open the page or refresh part of it:
>
> public class ExtraDataForm extends Form {
>
> ................
>
> @Override
> protected void onBeforeRender() {
> setDataBaseVersion(getModelVersion());
> super.onBeforeRender();
> }
>
> }
>
> In order to update the version when saving I had to "force" the version into the extraDataNew object:
>
> add(new Button("btnSave") {
> @Override
> public void onSubmit() {
> try {
> final ExtraDataNew extraDataNew = (ExtraDataNew)extraDataModel.getObject();
> extraDataNew.setVersion(getDataBaseVersion());
> edManager.saveExtraDataNew((ExtraDataNew)extraDataModel.getObject());
> info("Extra data saved.");
> } catch (Exception e) {
> log.error("Could not save: ",e);
> error(e.getMessage());
> }
> }
> });
>
> That's why I need to test the Page using two different sessions.
>
> Thanks
> Daniele Cremonini
>
> -----Original Message-----
> From: jcarman@carmanconsulting.com [mailto:jcarman@carmanconsulting.com] On Behalf Of James Carman
> Sent: 08 October 2010 12:13
> To: users@wicket.apache.org
> Subject: Re: Testing concurrant updates on database
>
> What exactly are you trying to test? Are you trying to test the
> optimistic locking? You didn't write that. If you want to test that
> you actually have optimistic locking turned on, then you can do that
> by checking the metadata.
>
> On Fri, Oct 8, 2010 at 3:27 AM, CREMONINI Daniele
> <Da...@ext.efsa.europa.eu> wrote:
>> Hi everybody,
>>
>> My problem is I have to test a Page that should prevent lost updates via optimistic lock checking.
>>
>> I resolved the problem using JPA optimistic lock and if I use two different browsers then the Page works in the desired way.
>>
>> The problem comes in the test phase: to emulate two concurrent sessions I would instantiate two pages accessing to the same object (record) on the database this way having two sessions that I will call A and B.
>> Then on the session A I update and save (everything is expected to be correct), then on session B I update and save (an exception is expected to be thrown).
>>
>> My approach might be
>>
>> final WicketTester.DummyWebApplication testWebApplication1 = new WicketTester.DummyWebApplication() ...
>> final WicketTester.DummyWebApplication testWebApplication2 = new WicketTester.DummyWebApplication() ...
>>
>> ...
>>
>> tester1 = new MyAppWicketTester(testWebApplication);
>> tester2 = new MyAppWicketTester(testWebApplication);
>>
>> tester1.startPage(new ITestPageSource() ...
>> tester2.startPage(new ITestPageSource() ...
>>
>> but as soon as run the complete set of test anything "blow up".
>>
>> Do you have any suggestion?
>> Thanks
>> Daniele Cremonini
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
> ______________________________________________________________
> This message has been scanned for viruses.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
______________________________________________________________
This message has been scanned for viruses.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Testing concurrant updates on database
Posted by James Carman <ja...@carmanconsulting.com>.
You're really not supposed to be monkeying with the version property
yourself. You're supposed to let the ORM provider do that. What I
would do is create a hidden field and put a validator on that. The
validator would check to make sure that the current version in the
database is the same as what you got when you read the record out
initially. You then just basically need to test that this works
properly (using mock objects for your DAOs). You can assume that the
database ORM provider's locking works property, or at least I would.
To make sure nobody turns off the optimistic locking in the future,
just add in a unit test case that validates that the optimistic
locking is turned on by checking the metadata.
On Mon, Oct 11, 2010 at 4:00 AM, CREMONINI Daniele
<Da...@ext.efsa.europa.eu> wrote:
> Thank you for your reply.
>
> I'm using Wicket 1.3.4.
>
> The optimistic locking is enabled for sure (the program has been written by me) and metadata and data confirm that things are actually functioning the way I thought.
>
> Because the Page contains a LoadableDetachableModel, every time I submit the page, Wicket reloads the object overwriting the version attribute.
> To workaround this behaviour I overridden the onBeforeRender method to save the version as soon as I open the page or refresh part of it:
>
> public class ExtraDataForm extends Form {
>
> ................
>
> @Override
> protected void onBeforeRender() {
> setDataBaseVersion(getModelVersion());
> super.onBeforeRender();
> }
>
> }
>
> In order to update the version when saving I had to "force" the version into the extraDataNew object:
>
> add(new Button("btnSave") {
> @Override
> public void onSubmit() {
> try {
> final ExtraDataNew extraDataNew = (ExtraDataNew)extraDataModel.getObject();
> extraDataNew.setVersion(getDataBaseVersion());
> edManager.saveExtraDataNew((ExtraDataNew)extraDataModel.getObject());
> info("Extra data saved.");
> } catch (Exception e) {
> log.error("Could not save: ",e);
> error(e.getMessage());
> }
> }
> });
>
> That's why I need to test the Page using two different sessions.
>
> Thanks
> Daniele Cremonini
>
> -----Original Message-----
> From: jcarman@carmanconsulting.com [mailto:jcarman@carmanconsulting.com] On Behalf Of James Carman
> Sent: 08 October 2010 12:13
> To: users@wicket.apache.org
> Subject: Re: Testing concurrant updates on database
>
> What exactly are you trying to test? Are you trying to test the
> optimistic locking? You didn't write that. If you want to test that
> you actually have optimistic locking turned on, then you can do that
> by checking the metadata.
>
> On Fri, Oct 8, 2010 at 3:27 AM, CREMONINI Daniele
> <Da...@ext.efsa.europa.eu> wrote:
>> Hi everybody,
>>
>> My problem is I have to test a Page that should prevent lost updates via optimistic lock checking.
>>
>> I resolved the problem using JPA optimistic lock and if I use two different browsers then the Page works in the desired way.
>>
>> The problem comes in the test phase: to emulate two concurrent sessions I would instantiate two pages accessing to the same object (record) on the database this way having two sessions that I will call A and B.
>> Then on the session A I update and save (everything is expected to be correct), then on session B I update and save (an exception is expected to be thrown).
>>
>> My approach might be
>>
>> final WicketTester.DummyWebApplication testWebApplication1 = new WicketTester.DummyWebApplication() ...
>> final WicketTester.DummyWebApplication testWebApplication2 = new WicketTester.DummyWebApplication() ...
>>
>> ...
>>
>> tester1 = new MyAppWicketTester(testWebApplication);
>> tester2 = new MyAppWicketTester(testWebApplication);
>>
>> tester1.startPage(new ITestPageSource() ...
>> tester2.startPage(new ITestPageSource() ...
>>
>> but as soon as run the complete set of test anything "blow up".
>>
>> Do you have any suggestion?
>> Thanks
>> Daniele Cremonini
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
> ______________________________________________________________
> This message has been scanned for viruses.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Testing concurrant updates on database
Posted by CREMONINI Daniele <Da...@ext.efsa.europa.eu>.
Thank you for your reply.
I'm using Wicket 1.3.4.
The optimistic locking is enabled for sure (the program has been written by me) and metadata and data confirm that things are actually functioning the way I thought.
Because the Page contains a LoadableDetachableModel, every time I submit the page, Wicket reloads the object overwriting the version attribute.
To workaround this behaviour I overridden the onBeforeRender method to save the version as soon as I open the page or refresh part of it:
public class ExtraDataForm extends Form {
................
@Override
protected void onBeforeRender() {
setDataBaseVersion(getModelVersion());
super.onBeforeRender();
}
}
In order to update the version when saving I had to "force" the version into the extraDataNew object:
add(new Button("btnSave") {
@Override
public void onSubmit() {
try {
final ExtraDataNew extraDataNew = (ExtraDataNew)extraDataModel.getObject();
extraDataNew.setVersion(getDataBaseVersion());
edManager.saveExtraDataNew((ExtraDataNew)extraDataModel.getObject());
info("Extra data saved.");
} catch (Exception e) {
log.error("Could not save: ",e);
error(e.getMessage());
}
}
});
That's why I need to test the Page using two different sessions.
Thanks
Daniele Cremonini
-----Original Message-----
From: jcarman@carmanconsulting.com [mailto:jcarman@carmanconsulting.com] On Behalf Of James Carman
Sent: 08 October 2010 12:13
To: users@wicket.apache.org
Subject: Re: Testing concurrant updates on database
What exactly are you trying to test? Are you trying to test the
optimistic locking? You didn't write that. If you want to test that
you actually have optimistic locking turned on, then you can do that
by checking the metadata.
On Fri, Oct 8, 2010 at 3:27 AM, CREMONINI Daniele
<Da...@ext.efsa.europa.eu> wrote:
> Hi everybody,
>
> My problem is I have to test a Page that should prevent lost updates via optimistic lock checking.
>
> I resolved the problem using JPA optimistic lock and if I use two different browsers then the Page works in the desired way.
>
> The problem comes in the test phase: to emulate two concurrent sessions I would instantiate two pages accessing to the same object (record) on the database this way having two sessions that I will call A and B.
> Then on the session A I update and save (everything is expected to be correct), then on session B I update and save (an exception is expected to be thrown).
>
> My approach might be
>
> final WicketTester.DummyWebApplication testWebApplication1 = new WicketTester.DummyWebApplication() ...
> final WicketTester.DummyWebApplication testWebApplication2 = new WicketTester.DummyWebApplication() ...
>
> ...
>
> tester1 = new MyAppWicketTester(testWebApplication);
> tester2 = new MyAppWicketTester(testWebApplication);
>
> tester1.startPage(new ITestPageSource() ...
> tester2.startPage(new ITestPageSource() ...
>
> but as soon as run the complete set of test anything "blow up".
>
> Do you have any suggestion?
> Thanks
> Daniele Cremonini
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
______________________________________________________________
This message has been scanned for viruses.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Testing concurrant updates on database
Posted by James Carman <ja...@carmanconsulting.com>.
What exactly are you trying to test? Are you trying to test the
optimistic locking? You didn't write that. If you want to test that
you actually have optimistic locking turned on, then you can do that
by checking the metadata.
On Fri, Oct 8, 2010 at 3:27 AM, CREMONINI Daniele
<Da...@ext.efsa.europa.eu> wrote:
> Hi everybody,
>
> My problem is I have to test a Page that should prevent lost updates via optimistic lock checking.
>
> I resolved the problem using JPA optimistic lock and if I use two different browsers then the Page works in the desired way.
>
> The problem comes in the test phase: to emulate two concurrent sessions I would instantiate two pages accessing to the same object (record) on the database this way having two sessions that I will call A and B.
> Then on the session A I update and save (everything is expected to be correct), then on session B I update and save (an exception is expected to be thrown).
>
> My approach might be
>
> final WicketTester.DummyWebApplication testWebApplication1 = new WicketTester.DummyWebApplication() ...
> final WicketTester.DummyWebApplication testWebApplication2 = new WicketTester.DummyWebApplication() ...
>
> ...
>
> tester1 = new MyAppWicketTester(testWebApplication);
> tester2 = new MyAppWicketTester(testWebApplication);
>
> tester1.startPage(new ITestPageSource() ...
> tester2.startPage(new ITestPageSource() ...
>
> but as soon as run the complete set of test anything "blow up".
>
> Do you have any suggestion?
> Thanks
> Daniele Cremonini
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org