RE: Testing concurrant updates on database
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: jcar...@carmanconsulting.com [mailto:jcar...@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
daniele.cremon...@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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
__
This message has been scanned for viruses.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
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
daniele.cremon...@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: jcar...@carmanconsulting.com [mailto:jcar...@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
daniele.cremon...@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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
__
This message has been scanned for viruses.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
RE: Testing concurrant updates on database
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: jcar...@carmanconsulting.com [mailto:jcar...@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
daniele.cremon...@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: jcar...@carmanconsulting.com [mailto:jcar...@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
daniele.cremon...@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
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 daniele.cremon...@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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
