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
For additional commands, e-mail: users-h...@wicket.apache.org
