MockWebApplication double invocation of cycle.detach()
MockWebApplication calls twice the detach method of cycle. I opened a issue and sent a patch: https://issues.apache.org/jira/browse/WICKET-3994 The solution seems very trivial to me so I ask if it may be verified and eventually scheduled for Wicket 1.4.19. Thanks Daniele
RE: could not serialize the page java.lang.OutOfMemoryError: PermGen space
It happens when the maximum amount of heap memory is reached. The solution is to increase a dedicated virtual machine parameter to a higher value. For example if you wish to increase to 256 megabytes use this: -XX:MaxPermSize=256m in your eclipse.ini file or in the right file of your application server. If the problem should arise anyway you should consider to examine memory leaks in your application. Let us know Bye Daniele Cremonini -Original Message- From: fachhoch [mailto:fachh...@gmail.com] Sent: 13 October 2010 16:25 To: users@wicket.apache.org Subject: could not serialize the page java.lang.OutOfMemoryError: PermGen space could not serialize the pagejava.lang.OutOfMemoryError: PermGen space , I got this error, it happens once in a while , its hard to reproduce, please tell me can wicket cause memory errors for any reason ? I am using 1.4.8 -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/could-not-serialize-the-page-java-lang-OutOfMemoryError-PermGen-space-tp2993745p2993745.html Sent from the Users forum mailing list archive at Nabble.com. - 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
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
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
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