IDE: Visual Studio, C# .net 4.0, Winforms application
Is there any way in SQL Server to implement a column in a table which can set itself automatically to 0 when it has not received any ACK (acknowledgement) signal from the application side?
The requirement is I want to keep a column which can keep track that Is application is open or it has been closed?
One way to implement is using the OnClose() event, i.e. on Close() I can change it's value to 0. but the problem is suppose application got hanged for some reason or Power is gone than the value in database will not be updated to zero.
So I want to create an automated column which can track this situation and make itself zero when the application is not sending any request or idle means closed.
please suggest how to handle this.
You can't do that. The only thing you can do is to save GETDATE() in a column in a table as the last activity time of the application and invoke the stored procedure from a high-priority thread every 10 seconds for example.
When you want to know if the application is alive or not, just check this value, if more than 10 seconds is passed since then, you app is gone.
UPDATE:
A more precise but complex approach would be to listen on a socket inside your application and then whenever you want to know if the application is alive, send a request from your sql script to PING the application. You should use CLR programming for this approach, but I think the first one will be practically enough.
Considering it will be a multiple instance scenario where multiple instances of the application can point to same database. You can try the following:
Create a separate table to maintain sessions. This table would contain three columns 1)Machine name or IP 2) Session Id (GUID) and 3) TimeStamp.
Whenever application starts create a new session id and make an entry into this table it means new session is started.
Keep on updating timestamp on every request based on session id.
Have a timeout configured somewhere in web.config or database which will come in handy later.
Now when application is exiting gracefully then delete the row from the table.
Now if application crashes the row won't be delete so next time when application starts you can check if the row already exists. Use machine name or IP to query to the table.
Use the timeout setting configured in (3) above to determine since how long the application is idle.
Related
I need to create an ASP.NET web service that simply returns an information telling if a database is available or down when it's consumed.
So I would like to know if I can set a task that is executed inside the web service method on a regular basis to check the connection to the database and return the result via a URL.
No you cannot. Well, you could, but you really should not. A webservice is on demand. If it's called, it does work. If it's not called, it's not running.
You may have been thinking of a windows service. That is something that is always running and can do stuff in the background.
(A windows service may have an additional web frontend to see it's data. Or any other way to visualize it's data points, for example another database.)
As you tagged c# and asp so you are using Sql server database,
this query gives you databases that exists on your sql server instance:
select * from master.dbo.sysdatabases
result contains name and some extra information, name gives you database names, mode column have a int value indicates that database is in creating mode or created mode, status column that contains a int value(power of 2)
If you would like to see if database is offline or not, you can see status value if it is 512 your database is offline, for 1024 it is in read only mode
for your service you can use web api, web method or wcf, it is depend on you
If you use hangfire, quartz or any other scheduler you can set a background job on your server to check your database status
"return the result via a URL" I can not understand this, but if you want to notify users about database you can use push notification on your background job
I have a question concerning redis in a distributed architecture.
Assume I have n clients, either windows desktop applications or asp.net web/web api servers.
One of the clients, lets say client A, hits the cache for a data and has a miss (the data is not in the cache). The client then starts to get the real data (from lets say a database) and then sets it in the cache when it's done.
Client B comes along and wants the same data, does a fetch to the cache and since it's a miss, does the same processing.
Is there a way for Client B to ...(N) not to do the processing (i.e go to the database) until the data is in the cache and fetch the data from the cache instead when it's available?
I understand that on a single app (or web server), using threads it's easy to check that, but in a distributed architecture?
Is this also a correct way of thinking as well? for the wait process that is
If so then could Client A put a flag somewhere stating that he's loading Data X and that all other clients should wait until he's done?
Otherwise, the idea then would be something along the lines of :
Client A requests Data X
Miss in cache
Processes Data X
Looks if Data X is now in cache
If not, add Data X to cache, otherwise, use it and don't store it in cache
Thanks!
As Kevin said, it's called cache stampede.
One of the best documents to do with this problem I have read is Using memcached: How to scale your website easily (comes from Josef Finsel):
What we need in this instance is some way to tell our program that
another program is working on fetching the data. The best way to
handle that is by using another memcached entry as a lock.
When our program queries memcached and fails to find data, the first
thing it attempts to do is to write a value to a specific key. In our
example where we are using the actual SQL request for the key
name we can just append ":lock" to the SQL to create our new key.
What we do next depends on whether the client supports returning
success messages on memcached storage commands. If it does,
then we attempt to ADD the value. If we are the first one to attempt
this then we’ll get a success message back. If the value exists then
we get a failure indication and we know that another process is trying
to update the data and we wait for some predetermined time
before we try to get the data again.
When the process that’s updating
the cache is done, it deletes the lock key.
I'm coding a M2M data capture system using SQL Server 2012 and .net 4.5, the scenario is:
I have a remote data capture app, a web service, a DB.
The app captures data and invoke the web service to upload the data to the DB.
The web service call a "insert" storedproc to write raw data directly in Table A; and then, the web service returns a value telling that the insert was successful or not.
Now, a post-process storedproc needs to be run after the insert process to update another table (Table B).
Previously I used 'job agent' but since the required polling interval changed to 'less than 5 minutes', for the efficiency and real-time reason, I want to avoid to use the 'polling'.
Ideally, I want the app to be able to call the web service and get the return message/value, after that, the DB fires a stored proc to do the post-process work; the work may take longer so the app doesn't need to wait all the processes are done.
Can I fire the post-process sp from DB side? since the DB knows when the insert is done, and it saves communications from outside the DB.
Any suggestions?
You might think of using trigger plus Service Broker. In this way, the trigger will send a message to a queue. service broker will be fired to process the message. It decouples your table A update and table B update. If only use trigger to call table B, it will hold your table A update until the table B update finished.
I build web-site and want to count clicks on some button. I create and try this class of counter:
public static class Counter
{
public static int counter = 0;
}
Every time I click on the button the counter is increament (counter++) ans I see it in my site, But, if I close the chrome and enter again to my site the counter starts from zero.
How can I save the counter? "Static" dont need to do that?
My bet is that it happens because the application space is flushed - it shouldn't reset just because you closed your browser window, thus abandoning the current session (if the session cookie isn't persistent, that is.)
Visual Studio may republish your files (if using a remote IIS) or just plainly restart a local IIS Express instance, depending on how you set your development environment; I do believe setting a specific content as Static would cause it to be available to all current sessions.
That said, you may want to keep it under the current session (using the Session object).
Optionally, if you want to persist information in between server restarts, you may try reading and writing to a local storage, such as a plaintext or XML file. You can find a very nice article about this on the following link:
http://www.codeproject.com/Articles/544839/Implement-ASP-NET-custom-XML-file-configuration
A more sophisticated version would use a local (or remote) database, for example.
Hope it works for you.
static fields are unique per-process. Depending on your application pool configuration, you could have 2, 20 or 100 copies of that.
They're also not thread safe. There are very, very few instances (pun) where a static member is appropriate.
Just off the top of my head, a particular "instance" of a static will disappear when:
The application pool is recycled. On IIS, this defaults to 20 minutes of inactivity.
The application process exits (you may have multiple processes running within your app pool). This happens as part of (1), but will also happen if, say, you're using the Visual Studio debug web server (Cassini), have your project configured to launch the site for debugging, and close the browser that was launched initially. (This happens because VS considers closing the browser that it launched equivalent to saying "I'm done playing. Back to coding now," or hitting the stop button.)
Another thread overwrites the value you've stored (google "race condition.")
You really, really should be storing this in a database. If you're building a website, you need a database anyway. ANYTHING related to application state should be stored in the database.
ALSO, this really, really shouldn't be happening server-side. Are you really performing a postback every time someone clicks anywhere on a page? If so, you have JavaScript in place to handle that, so just skip this insanity, have said script fire off an AJAX request, and have the target handler log it in the database.
Looks like your using a web site so presuming ASP.net. There are a number of ways to store the information. Database could be one or a persistent cookie could be the way to do it. See this article on how to create cookies: How do I set/unset cookie with jQuery?
You can try save it in session and then it will stay until the session is time out(20 minutes) if you want it to long time just write it to file in known location and when you close the web write the value to the file and when the web is up again take the vakue from the file.
In my database on my SQL Server I have a table with users. This table have a column named logged_on which is a bit, either true or false. When someone log on the column will be true, else false. If something ever happens when someone is using my wpf-application, like the power disappears and the application couldn't log out the user this column will be true and the user will not be able to login again, because the application will tell this user that he is already logged on. Is there something i could do to avoid this situation? On the server-side or in the application?
Any sugestions are appreciated :)
I think you'll need a "LastActive" date-time stamp. Then run a scheduled job that says "if you've been inactive for X minutes, change the state of the logged_on flag".
Are you trying to insure that only one login can be active at the same time? Is that the end game?
Sounds like you need to change the approach a little, perhaps tracking last interaction date/time (every time the WPF app calls SQL) and enforcing a session timeout limit instead. You could use that DateTime to automatically log out anyone that hasn't interacted with the server in several minutes by checking it in addition to the *logged_on* bit field (always switching *logged_on* to false if the DateTime is too stale).
Is there an important reason you can't just throw away the old login in situations where the user logs in again without logging out first?