Is this possible to prevent database connection while I requests concrete action in Zend Framework 2?
As Sam stated in a comment; if you do not wish to establish a connection to the database, then simply don't. If you do not have any code within your controller action that uses the database, then there won't be a database connection (provided that you are not doing funky stuff in a bootstrap method or similar).
If you are building a database connection in the standard way, then the actual connection will be lazily loaded, meaning that there won't be an actual connection before you try to use it.
In your comment you state that you believe the problem is caused by many database connections. I just want to clarify that there will only be one database connection per request (provided that you make use of the database).
If you have no code that calls a database, then your web server won't actually make a connection to your database. Either way, if you have 150+ images per page, then that would be a bigger concern and is probably the root cause for slow page loads. Perhaps consider pagination or if you do not display the pictures in their full sizes, then avoid scaling them in HTML as you would then be sending lots of unnecessary data from your web server to your visitors. You could resize the pictures in PHP when they are added, for instance. After that, you could even consider using a Content Delivery Network (CDN), but that is a different discussion...
Related
I'm working with React-Redux and I've been looking at libraries to manage to sync my data with the server. I've seen libraries like react-offline and react-persist that handle parts of my problem, but not all of it. I have these requirements:
I have control of the API, so I can change it in any way necessary
I don't want to send the entire data set to the client. Users will only have access to a subset of the data in the database
I want the application to be able to be disconnected from the internet and still run normally (the area it functions in might are spotty, or totally disconnected)
On login, a client will request all the data it will have access to
At intervals, it will request a list of changes to the data it has access to so it can reconcile the client data locally (and invisibly)
At intervals, or when changes occur (configurable), it will send a batch of all changes the client has made to the server
Please let me know if there are redux libraries that handle all these requirements. Also, feel free to comment if some of the requirements feel like an overengineering or not best practice.
Thanks in advance!
I'm trying to figure out how to create an offline / online approch to use within a huge application.
Right now, each part of the application has its own model and datalayer, who directly read / write data from / to SQL. My boss is asking me to create a kind of buffer that, in case of connectivity failure, might be used to store data until the connection to SQL return active.
What I'm trying to create is something like this: move all datalayers into a servicestack service. Each "GET" method should query the database and store the result into a cache to be reused once the connection to SQL is not available. Each "POST" and "PUT" method must execute their actions or store the request into a cache if the connection fail. this cache must be cleared once the connection to SQL is restored.
How can I achieve this? Mine is a WPF application running on Windows 10.
Best regards
Enrico
Maintaining caches on the server is not going to help create an offline Application given the client wouldn't have access to the server in order to retrieve those caches. What you'd need instead is to maintain state on the client so in the event that network access is lost the client is loading from its own local caches.
Architecturally this is easiest achieved with a Web App using a Single Page App framework like Vue (+ Vuex) or React (+ Redux or MobX). The ServiceStack TechStacks and Gistlyn Apps are good (well documented) examples of this where they store client state in a Vuex store (for TechStacks created in Vue) or Redux Store (for Gistlyn created in React), or the Old TechStacks (created with AngularJS).
For good examples of this checkout Gistlyn's snapshots feature where the entire client state can be restored from a single serialized JSON object or approach used the Real Time Network Traveler example where an initial client state and delta's can be serialized across the network to enable real-time remote control of multiple connected clients.
They weren't developed with offline in mind, but their architecture naturally leads to being offline capable, courtesy of each page being first loaded from its local store then it fires off a Request to update its local cache which thanks to the reactivity of JS SPA fx's, the page is automatically updated with the latest version of the server.
Messaging APIs
HTTP has synchronous tight coupling which isn't ideal for offline communication, what you want instead is to design your write APIs so they're One Way/Asynchronous so you can implement a message queue on the client which queues up Request DTOs and sends them reliably to the server by resending them (using an exponential backoff) until the succeed without error. Then for cases where the client needs to be notified that their request has been processed they can either be done via Server Events or via the client long-polling the server checking to see if their request has been processed.
i have a scenario where i have to load data from SQL server when i start running a web service. Later i have to use this data for my application, instead of accessing it every time from Database. In addition to this this data should be refreshed every one hour without affecting the website operation on the back end.If any of you has came across such scenario please let me know the solution. By the way i am using asp.net web services, SQL server database, and DNN for my front end.Thanks in advance.
In Global Asax,Application start event you can load all your data in the Dataset.
And by using Sql Cache dependency, You can refresh the data for each hour.But loading the
Entire data is not advisable.By making so you memory will be full.There will
be Performance degrade.
http://www.codeproject.com/Articles/14976/ASP-NET-Caching-Dependencies
Pre-loading all of your data is not a good practice because the database loses its purpose then. It’s probably ok for some data that is very rarely updated but needed very frequently but most definitely not for all the data you have in database.
As for the loading of data you can use app start event as others have already suggested.
Regarding caching – use Application object to make this data available to all parts of application and add a proprety to it that will keep the time of the last update. Then just create separate service that will check the last update time every X minutes and refresh the data when the time comes.
I am building a website (probably in Wordpress) which takes data from a number of different sources for display on various pages.
The sources:
A Twitter feed
A Flickr feed
A database on a remote server
A local database
From each source I will mainly retrieve
A short string, e.g. for Twitter, the Tweet, and from the local database the title of a blog page.
An associated image, if one exists
A link identifying the content at its source
My question is:
What is the best way to a) store the data and b) retrieve the data
My thinking is:
i) Write a script that is run every 2 or so minutes on a cron job
ii) the script retrieves data from all sources and stores it in the local database
iii) application code can then retrieve all data from the one source, the local database
This should make application code easier to manage - we only ever draw data from one source in application code - and that's the main appeal. But is it overkill for a relatively small site?
I would recommend putting the twitter feed and flickr feed in JavaScript. Both flickr and twitter have REST APIs. By putting it on the client you free up resources on your server, create less complexity, your users won't be waiting around for your server to fetch the data, and you can let twitter and flickr cache the data for you.
This assumes you know JavaScript. Once you get past JavaScript quirks, it's not a bad language. Give Jquery a try. JQuery Twitter plugin Flickery JQuery plugin. There are others, that's just the first results from Google.
As for your data on the local server and remote server, that will depend more on the data that is being fetched. I would go with whatever you can develop the fastest and gives acceptable results. If that means making a REST call from server to sever, then go for it. IF the remote server is slow to respond, I would go the AJAX REST API method.
And for the local database, you are going to have to write server side code for that, so I would do that inside the Wordpress "framework".
Hope that helps.
In ASP.NET, I usually log exceptions at server-side, In windows forms I can either log exceptions server-side or write to a log file on the client. Silverlight seems to fit somewhere in between.
I wanted to know what everyone else is doing to handle their Silverlight exceptions and I was curious if any best practices have emerged for this yet.
For real logging that you could store & track, you will need to do it on the server, since you can't be guaranteed anything on the client will be persisted.
I would suggest exposing a "LogEvent(..)" method on a server side web service (maybe you already have one) which would then do the same kind of logging you do in ASP.net
Here's a video about basic web service calls in Silverlight if you haven't done that yet
http://silverlight.net/learn/learnvideo.aspx?video=66723
I'm not sure about any logging best practices though, my first guess would be to do the best practicies for logging in a web sevice on the server and expose that to the client.
Hope this helps!
I would say that Silverlight fits much better to ASP.NET side of the model. You have server which serves web page. An object (Silverlight app) on the page pings data service to fetch data and display it.
All data access happens on the server side and it does not matter if data is used to create ASP.NET pages on the server or sent raw to the RIA for display. I do log any failures in data service on server side (event log works fine) and do not allow any exception to pass to WCF. When client does not receive expected data (it gets null collection or something similar), it display generic data access error to the user. We may need to extend that soon to pass a bit more information (distinguishing between access denied/missing database/infrastructure failure/internal error/etc), but we do not plan to pass exception error messages to the client.
As for client side, sometimes we may get in situation where async call times out -- it is just another message. For general exceptions from client code (typically, bugs in our code), I just pass exception to the browser to display in same manner as any script exception.
Also take a look at the new Silverlight Integration Pack for Enterprise Library from Microsoft patterns & practices. It provides support for logging exceptions to isolated storage or remote services and is configurable via policies in external config or programmatically. Batch logging and automatic retry (in case of occasionally connected scenarios) are also supported.
Use the Isolated Storage available for Silverlight application. You should store here your log.
Then you can develop a mecanism to send the user log to a webservice like the Windows bug report service.
It very much depends on the type of application that youre developing.
if its an mvc / mvp based architecture then your model, or most of it at least, will be on the server, and this is where most of your exceptions will be thrown i would imagine, so you can log them there and choose to display a message to the user or not.
for exceptions from the client you may want to know the details so just send them back.