04-21-2017 12:32 AM
When using GeoMedia WebMap we may choose to work with several MapServers. Each MapServer caches the connection to the warehouse. If we now digitize and one MapServer it writes this information to the warehouse. Then the map gets refreshed but the new content on the map only displays if the same MapServer has been chosen by the MapServerManager. If another MapServer is chosen randomly then the changes, which have been made to the warehouse are not visible on the map.
For our local product, we use a workaround for years. We force the program to close and reopen the connection to the warehouse to be able to display the new content. With better machines our customers started to use more MapServers at the same time, what slows down the performance. Therefore the question:
Is it possible to update the content of the warehouse with broadcast database changes so we don't need to close and re-open the connection to the warehouse every time?
04-24-2017 03:04 AM
I'm unaware of any such capabilities in the core Connection object.
What you could do, however, is to reopen only the GRecordset that you are using, instead of the whole Connection object. This might be more performant, as there will be no reloading of GDO metadata.
var notification = (Notification)recordset.GetExtension("Notification"); notification.Reopen();
This will work only for OriginatingPipe based GRecordsets, though.
Actually, this is what WebMap does in its standard workflows, and that's why there is no issue with obtaining WFS features modified through a transaction request from a different MapSvr.exe process.
04-26-2017 07:44 AM
This is sadly not working. Probably because the WFS uses the export services which use directly the recordsets. We use the CreateMapByRange() method that most likely uses a different caching mechanism with the legend entries.
There's also a ReloadDatabase() Method on the connection object that also does not have any effect when using the CreateMapByRange() method.
So far only the hard way, disconnecting and reconnecting the connection, leads to the correct result.
04-26-2017 08:03 AM
MapSvr::CreateMapByRange operates on the Legend object which is built from LegendEntry objects each of which references a Recordset. This method also applies spatial filtering, which actually does the Notification::Reopen. AFAIK, Connection::ReloadDatabase results in closing and reopening all the OriginatingPipe objects, which is in fact what Notification::Reopen does.
Now I'm stumped. I wonder if that's because you use a specific warehouse connection type. Can you provide more details on your setup and implementation?
04-27-2017 12:04 AM
|Ausflugsrouten||Access.GDatabase||D:\BM Data\BM Geodaten\Access\Schweiz\Digitalisieren\Ausflugsrouten.mdb||Read/Write||Open|
WebMap is Version 16.00.0200.00004 Professional, with 2 MapSvr.exe running. However, this problem exists since I know WebMap, from 6.1.
We draw something in the map and press save -> ajax to server -> get a free mapserver -> connect to the db if not cached -> get the grecordset -> call addNew and then update -> status code 200 with connection name
As soon as this succeeded -> new ajax to server to request the new map, connection name is passed -> get a free mapserver -> use the connection name to disconnect/reconnect the cached connection -> connect to lib -> call getFromLibrary -> append legendEntries to mapserver -> call CreateMapByRange
So, the part use the connection name to disconnect/reconnect the cached connection looks like this:
Public Function refreshMapServerConnections(strConnectionName) Dim objConn For Each objConn In m_objMapServer.Connections If UCASE(objConn.Name) = UCASE(strConnectionName) Then m_objMapServer.WriteLog 5, "BM: reload database connection " & strConnectionName Dim connection: set connection = m_objMapServer.Connections(strConnectionName) 'connection.Disconnect() 'connection.Connect() 'connection.ReloadDatabase() Dim origPipes: set origPipes = connection.GetOriginatingPipes() Dim origPipe For Each origPipe In origPipes Dim notification: set notification = origPipe.OutputRecordset.GetExtension("Notification") notification.Reopen() m_objMapServer.WriteLog 5, "BM: reopen notification " & origPipe.table Next m_objMapServer.WriteLog 5, "BM: reload database connection done" End If Next End Function
Only the disconnect() connect() variant guarantees me, that the new geometry object is contained in the png or svg map on every mapserver.
2 weeks ago
Apologies for the very late reply.
I've just made a test using out-of-the-box services of WebMap:
WFS-T -> Oracle R/W Warehouse -> WMS
After editing the warehouse (inserting, moving, deleting), all the changes are reflected correctly in the WMS (which images were not necessarily served by the same map server).
I start wondering if the behavior you experience isn't caused by the way the Access GDO Data Server works. But to confirm that, we'd need maybe someone from the GeoMedia team to chime in.
2 weeks ago
I appended an asp classic test script. It generates each time you load the page a new random point and saves it to the database and afterwards another mapserver generates a simple map showing the points stored in the database. If you have enough mapservers, you should be able to see that points can disappear on the map after a page refresh. This example indeed uses the Access data provider, I will try it with a different one too.
2 weeks ago - last edited 2 weeks ago
It is my current understanding that the behavior you are observing is in fact caused by the Access.GDatabase type of GDO Data Server you are using. It doesn't seem to have the proper db advisor machinery put in as do the other GDO Data Servers do. It also uses an almost straight MS DAO pass-through logic, which might or might not cause caching problems. I've tried writing into a GeoMedia Access Warehouse using OriginatingPipe created Recordsets and then reading through a plain DAO OpenRecordset. This kinda worked, but there seems to be some kind of lag.
When I had one program write changes using GeoMedia GDO, and the other read that out using GeoMedia GDO as well, no changes were reflected at any time unless the connection object were to be reopened manually.
I've scoured (read: only skimmed the surface of) the web for any information on potential mechanisms inside DAO for "pinging" readers to reread the recordsets, but couldn't find anything useful. DAO information seems to be very scarce these days and not very user-friendly.
Let us know what are the results of your tests with other connection types.
Fun side note: the MS Access Warehouse connection type seems to be one of the first ever created
Thanks for your answer. I've tested with the PostGISRW.GDatabase data server and couldn't observe the described issue. Indeed the issue seems to be limited to the Access.GDatabase data server. So I'll use the disconnect/connect workaround only for this data server type.