I was thinking in having the connection as a singleton for each user so they do not open and close continously. Not sure if this will solve the problem though
On above, I would say if you can confirm that MySQL does not pool connections, than using a Singleton is the way to go when managing a bunch of connections being opened and closed often. However my next few comments really void the whole 'polling'
approach anyways and this might be a moot point.
For the remainder, I am going to stick directly to your questioning line since it seems that your mine is made up on the technologies being used (Flash and .NET), but I agree with Kris in looking to HTML5 web sockets in the future. See the idea is that rather
than poll for the data you could use one of the many options to push
data to the client. HTML5 web sockets is the best bet in the future. As of today with purely .NET technologies I would recommend a WCF Duplex service with a Silverlight client (see
here). COMET is another way to push data to the client today (see
here). So you see I would begin to look at technologies and method in the long run that
push data to the client rather than relying on the client pulling
(via polling every 1 second) the data from the server. You have lots of options.
I am making a stretch here because I am not a Flash developer, but I did find some documentation on using sockets with Flash to potentially push data to your client (you have to investigate further on Flash forums probably to see if this is the correct method).
This might take some work to re-engineer from your current poll of the db every 1 second, but the effort will be worth what you get back in smoothness and performance.
atconway
All-Star
16846 Points
2756 Posts
Re: Connecting every 1 second to DB
Apr 30, 2012 06:42 PM|LINK
On above, I would say if you can confirm that MySQL does not pool connections, than using a Singleton is the way to go when managing a bunch of connections being opened and closed often. However my next few comments really void the whole 'polling' approach anyways and this might be a moot point.
For the remainder, I am going to stick directly to your questioning line since it seems that your mine is made up on the technologies being used (Flash and .NET), but I agree with Kris in looking to HTML5 web sockets in the future. See the idea is that rather than poll for the data you could use one of the many options to push data to the client. HTML5 web sockets is the best bet in the future. As of today with purely .NET technologies I would recommend a WCF Duplex service with a Silverlight client (see here). COMET is another way to push data to the client today (see here). So you see I would begin to look at technologies and method in the long run that push data to the client rather than relying on the client pulling (via polling every 1 second) the data from the server. You have lots of options.
I am making a stretch here because I am not a Flash developer, but I did find some documentation on using sockets with Flash to potentially push data to your client (you have to investigate further on Flash forums probably to see if this is the correct method). This might take some work to re-engineer from your current poll of the db every 1 second, but the effort will be worth what you get back in smoothness and performance.
flash.net: public class Socket:
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/net/Socket.html
Hope this helps!