[mapguide-internals] Avoiding unnecessary Tile Cache invalidation (Trac Ticket 1332)

[Tom Fukushima]

Sorry, when I wrote "This is only about the problem in the ticket", I should have said "This response from me is only about the problem in the ticket". I didn't mean to say we should ignore the "shared tile sets" idea, and I think it is something that is a good idea and would be good to do. I just don't have any input for it right now. Well, except that I think the reference to the tiled/base layers should stay in the MapDefinition...but that's just my feeling and further investigation needs to be done.

Tom

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Jason Birch
Sent: Tuesday, April 27, 2010 11:58 PM
To: MapGuide Internals Mail List
Subject: Re: [mapguide-internals] Avoiding unnecessary Tile Cache invalidation (Trac Ticket 1332)

Pushing tile sets into a separate resource would ensure that only
changes affecting the tile set would trigger a flush of the cache,
addressing the original issue. That's neither here nor there though.

I do like the idea of making tile cache deletion a manually triggered
event, with UI in Maestro (with four or five confirmation prompts) to
initiate :)  There's already an API call for this on a per-set basis,
isn't there?

Jason

On 2010-04-27, Tom Fukushima <tom.fukushima at autodesk.com> wrote:
> There are two problems being discussed now: the problem in the ticket (ie.,
> tile cache being deleted when we don't want it to be) and shared tile sets.
> This is only about the problem in the ticket.
>
> I had originally thought that option 2 would be a good short term solution
> as well, but in the end I don't like it and I think we should remove the
> autodelete altogether. Then as time permits put an interface into the server
> admin or Studio&Maestro that allows us to flush the cache manually.  The
> interface could inform us when a tile set becomes stale due to a resource
> change and then we could either undo the resource change or clear the cache
> or ignore the warning.
>
> For the short term, I think you can keep the server from deleting your tile
> sets by making the tile directory (and subdirectories and files) read only.
> I just tried this (made my C:\Program
> Files\MapGuide\Server\Repositories\TileCache\Samples_Sheboygan_MapsTiled_Sheboygan
> recursively read only) and it seems to work (and you can still create new
> tiles), but we should look at the code to verify.  Otherwise, (still for the
> short term) if the read only option doesn't pan out, I think that what we
> users should be doing is diligently making copies of the tile sets (a tool
> like XXCOPY can do this easily) and then use the copies to restore things if
> the tiles get deleted.
>
> Even though I suggested a solution in the ticket; I've changed my mind and I
> don't like trying to be smarter about automatic regeneration of the tiles,
> because in the end we can never be completely correct since we can't
> accurately monitor changes in the data (ie., we don't know when someone has
> changed the feature geometry or attributes in the Oracle database).
>
>
> Tom
>