Hi all,
I have been trying to solve this issue various ways for a couple of days now and would like some feedback from others.
Now the issue in question here is supporting lazy loading and the layer edit page which contains multiple tabs, one for the resource and one for the layer. This page uses two models for hanging onto the REsource and Layer respectively. And the models store the object directly, instead of the loading them from the catalog. And for good reason, this is done to maintain edits while the user switches between tabs.
Now where the problem comes up is with dbconfig and lazy initialization. Once a page reload occurs the layer and resource are serialized. However the objects contain lazy lists and association proxies that were created by hibernate as a result of lazy loading. So when they get serialized the session in which they were created is gone and they no longer function.
I tried solving this one a couple of different ways with varying degrees of success. Here is what I tried:
- Instead of store the objects use a map as the backing for the model
I actually did not get far with this one. It became evident very quickly that this would require a lot of changes
- Make each tab independent and forget about allowing the user to maintain changes between them
This one would involve changing the models back to models that load from the catalog rather than serialize the objects directly. And making each tab save independently. While this works we give up the ability to make changes on both tabs, switch between them and save. So the workflow takes a hit. Plus Andrea worked very hard to make that functionality possible so it would be a pity to throw it away. But i raise it as a possible solution.
- Add some catalog api to “dettach” the object
Currently the backing models for the patch call an “attach()” method on the catalog builder to set the catalog on the resource and the layer, since the catalog reference is transient. So what I thought of was using something similar. Not so much an attach but a dettach. The dettach would basically reload the object without lazy loading using a custom query of sorts. Then serialize that result. And it seems to be working for the most part. Although in some sequences of edits i have run into other issues around some proxies not being properly initialized.
So any thoughts? (3) seems to be the most promising at this point and does not require many changes to the page in question. But does not require some new catalog api.
Feedback welcome. Or if any of those wicket experts out there have any ideas they would be welcomed. I did some searching in the wicket forums and did not find all that much surprisingly. Most often the answer is “do not use lazy loading” 
-Justin
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
On Mon, Oct 4, 2010 at 7:14 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
Hi all,
I have been trying to solve this issue various ways for a couple of days now
and would like some feedback from others.
Now the issue in question here is supporting lazy loading and the layer edit
page which contains multiple tabs, one for the resource and one for the
layer. This page uses two models for hanging onto the REsource and Layer
respectively. And the models store the object directly, instead of the
loading them from the catalog. And for good reason, this is done to maintain
edits while the user switches between tabs.
Now where the problem comes up is with dbconfig and lazy initialization.
Once a page reload occurs the layer and resource are serialized. However the
objects contain lazy lists and association proxies that were created by
hibernate as a result of lazy loading. So when they get serialized the
session in which they were created is gone and they no longer function.
I tried solving this one a couple of different ways with varying degrees of
success. Here is what I tried:
1. Instead of store the objects use a map as the backing for the model
I actually did not get far with this one. It became evident very quickly
that this would require a lot of changes
2. Make each tab independent and forget about allowing the user to maintain
changes between them
This one would involve changing the models back to models that load from the
catalog rather than serialize the objects directly. And making each tab save
independently. While this works we give up the ability to make changes on
both tabs, switch between them and save. So the workflow takes a hit. Plus
Andrea worked very hard to make that functionality possible so it would be a
pity to throw it away. But i raise it as a possible solution.
3. Add some catalog api to "dettach" the object
Currently the backing models for the patch call an "attach()" method on the
catalog builder to set the catalog on the resource and the layer, since the
catalog reference is transient. So what I thought of was using something
similar. Not so much an attach but a dettach. The dettach would basically
reload the object without lazy loading using a custom query of sorts. Then
serialize that result. And it seems to be working for the most part.
Although in some sequences of edits i have run into other issues around some
proxies not being properly initialized.
So any thoughts? (3) seems to be the most promising at this point and does
not require many changes to the page in question. But does not require some
new catalog api.
Feedback welcome. Or if any of those wicket experts out there have any ideas
they would be welcomed. I did some searching in the wicket forums and did
not find all that much surprisingly. Most often the answer is "do not use
lazy loading"
Time allowing the third option seems the best one.
Mind one thing, there is a further user of those models, it's the sql view edit
page. I had to modify the layer pages quite a bit to make that one work
as well: it's tricky, because when you submit a change in that page you
go back into the layer one and the change made to the feature type
does not have to go into the catalog just yet, but only when the
user actually submits from the layer page. Yet, the feature type structure
displayed has to be updated according to the new sql view definition,
and to do that you have to make a direct call into the resource pool
I believe.
Cheers
Andrea
-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584962313
fax: +39 0584962313
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
-----------------------------------------------------