On Wed, Jan 11, 2012 at 2:59 AM, Andrea Aime
<[email protected]>wrote:
> On Wed, Jan 11, 2012 at 2:04 AM, Justin Deoliveira
> <[email protected]>wrote:
>
>> Yikes, indeed you are right, never considered that (obviously). But yeah,
>> I think the approach of having the LocalWorkspaceCallback maintain a list
>> of workspaces (keeping it up to date with a catalog listener) will work.
>
>
> Actually it's the OWSHandlerMapping, the LocalWorkspaceCallback should be
> invoked only by the OWS dispatcher, so not
> when working against the GUI I believe.
>
Ahh right, of course.
>
>
>>
>> Another alternative would be to have the callback maintain a thread local
>> cache of workspaces that it has already tried to look for, so as to only
>> pay the price for the first lookup. Could be a bit simpler and not have to
>> deal with synchronization, etc...
>>
>
> I'm worried this might end up defeating one of the purposes of having a
> database as a persistence layer, that is,
> having other applications modify directly the database.
> If we don't do queries and rely on a cache we'll basically ignore changes
> in the database.
>
By thread local I meant the cache would only live for the life of a single
request/thread. But yeah thinking more about that it doesn't make since if
i understand we are talking about multiple requests in this case.
>
> I'm wondering if there is any way to identify what is actually going to
> handle the request (rest, wicket, ows
> dispatcher?) and apply the workspace local management only on OWS ones?
>
Can't think of a great one off hand, this is sort of what the handler
mappings themselves specify... buts its hard to deterministically determine
that from their contents since its pattern passed. Although most of the
patterns are pretty simple. All in all i think Gabriels suggestion of a
catalog listener maintaing a list of workspaces names is probably the most
promising.
>
>
> Cheers
> Andrea
>
> --
> -------------------------------------------------------
> Ing. Andrea Aime
> GeoSolutions S.A.S.
> Tech lead
>
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
>
> phone: +39 0584 962313
> fax: +39 0584 962313
> mob: +39 339 8844549
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.youtube.com/user/GeoSolutionsIT
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
>
> -------------------------------------------------------
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel