[fdo-users] finally

Haris Kurtagic haris at sl-king.com
Tue May 19 16:00:54 EDT 2009


I guess PostGis provider is caching schema too. I don't know if it
allows for multiple simultaneous commands to run over one connection but
if it does then that could be same problem.

Real fix needs to be done in MapGuide. For our project I have changed
King.Oracle but that is just quick workaround to get us running.

I just realized I posted to FDO/MapGuide-user lists. 
I should post to internals too ? 

Haris

-----Original Message-----
From: fdo-users-bounces at lists.osgeo.org
[mailto:fdo-users-bounces at lists.osgeo.org] On Behalf Of doggybs
Sent: Tuesday, May 19, 2009 2:19 PM
To: fdo-users at lists.osgeo.org
Subject: Re: [fdo-users] finally


That is good news! I think I have been casing this problem for a while,
when
mapguide will lockup and crash when multiple users are viewing data from
the
postgis FDO.

Would it be possible for you to give some more details on how to setup
the
work arounds you have suggested.

Many Thanks
James



Haris Kurtagic wrote:
> 
> Finally we found what was causing MapGuide server to crash while
reading
> data from MapGuide.
> 
> It took us lot of energy and time.
> 
>  
> 
> Problem will appear in multiuser environment with concurent access
when
> you are using provider which is per command threaded or sharing
> (caching) FDO schema accross multiple connections.
> 
>  
> 
> Issue is in function:
> MgServerGetFeatures::SerializeToXml(FdoClassDefinition* classDef)
which
> will in order to serialize class to xml remove that class from schema,
> put it to temporary schema serialize and return class to original
> schema. While doing this if another thread goes to execute, problem
> starts.
> 
>  
> 
> Workaround is to set provider to per connection threaded or not cache
> schema at all, and both comes with perfomance penalties.
> 
>  
> 
> I think that few things are important in this case beside the obvious
> issue. One of them is missing constant pointers in FDO API. Schema
> returned from provider shouldn't be allowed to be changed by fdo
> clients. That is something were problems appeared already.
> 
> Also, I think that serialization using XML is not right way to go. XML
> we could use to serialize data to end-user not for internal MG
> processes.
> 
>  
> 
> Haris
> 
> 
> _______________________________________________
> fdo-users mailing list
> fdo-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-users
> 
> 

-- 
View this message in context:
http://n2.nabble.com/finally-tp2939043p2939178.html
Sent from the FDO Users mailing list archive at Nabble.com.

_______________________________________________
fdo-users mailing list
fdo-users at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-users


More information about the fdo-users mailing list