i am implementing a chat system in asp.net, much like google chat and i use xmhttp to send and receive data, and i am using a single table to store all chat for all user.
i wanted to create global temporary tables in sql using a XMLHttpRequest so as to be abl to organise data better(instead of storing all the chat in a sigle table which can(i dont know for sure) cause locking issues when many users are accessing it.)
also for my system i don't have to store the chat and so i thought that a global temporary table would be better since it will already be dropped and save me the trouble of clearing it.
but the after the table has been created by the Xmlhttprequest it gets dropped just after its creation....why this happen i don't know....i also have removed all connection closing lines but still no luck
so what should i do?? also if anyone knows of any online resources that can points me about best practices to follow please tell me.
Your table won't have locking issues with many users accessing it. Temporary tables are not meant to be shared cross-call, and you're going to wind up with far more roadblocks down that path. It is probably better to simply store your data in a table, then poll the table.
The only time you could have "locking issues" is if the users are attempting to write the same chunk of data to the same row at the same time ... which shouldn't be happening in a chat application.
Additionally, Google Chat uses a COMET style implementation instead of a polling implementation. It has been my experience that COMET > polling in terms of user experience.
You're not supposed to keep any chat messages on your database actually... unless you're implementing offline messages.
Related
Using Cloud Firestore as a database for my application.
The labels/images I use in the app are updated about once a day, if that, and are populated from the data saved onto my Firestore database.
I'm trying to weigh the pros of having a one-stop solution to my having my UI updated automagically and not having to deal with unreliable network on the user's behalf, and the cons of my application being a drain on both, the user's battery life and their data connection.
There are no documentations I can find on this, and the only source I have is this Firecast video where I can find some confirmation for the former use case.
I'm trying to figure out if I should go with manual fetches or active listeners.
If someone know about any documentation on this topic, I'd be thankful for it.
I'm still learning how to implement realm.io in my next project. I'm really amazed in the Realm Mobile Platform (offline-sync).
I'm reading https://realm.io/docs/realm-object-server/#access-control but what I need is preventing user accessing certain data in a model. (let's say they only can access data only their own data).
Thank You
In addition to the Realm documentation. There are a couple overviews on Multi-Realm setups you could check out. They go over permissions and database design.
https://realm.io/docs/tech-notes/multi-realm-cheatsheet/
https://realm.io/docs/tech-notes/teamwork/
I have an application that needs to send data to a cloud database (DynamoDb).
The app runs on a computer that can lose internet connectivity or be switched off at any time, but I must ensure that all data eventually gets to the cloud database.
I can assume the application will eventually be switched on, and will eventually get internet access back.
The app is written in VB .NET
What are some schemes for achieving this, and are there any ready-made products that already achieve this?
You could implement a write-through cache using a local DynamoDB instance (or even using SQLite). But without getting specific details about what kind of data you'd be storing into the database, and what data should be made available "offline" it's hard to say exactly how you should structure your application. You'll definitely want to not keep everything local, unless the volume of data is really small overall.
Then there is the problem of resolving conflicts that may occur during network partitions (ie. a client goes offline and makes some database modifications, while other clients also make modifications to the database; these need to be reconciled and it's up to you, and your users to determine how)
It's not a simple problem to solve.
I want to store some data during my site viewing.
Sometime i need to store large data like crystal reports and some times i need to store a string.
So which is best to use and when to use.
Where are these datas stored. i.e., Client or Server
Please go through this link:
Nine Options for Managing Persistent User State in Your ASP.NET Application
What you are asking is about State Management in ASP.NET. What you have actually listed is Server Side state management options.
You can made a choice of which to use depending on your requirement or functionality.
I will recommend you do some background reading on MSDN regarding State Management. I am not sure which answer you need here as your query is a bit generic.
Here is a link to get you started... http://msdn.microsoft.com/en-us/library/75x4ha6s.aspx
This is a very open ended question. Ass Julius said you need to learn more about the different ways you can store information. For example, Application is used when you want to store information on the initial startup of the site and make it available to all users. Session is for a single user so you may have many sessions open depending on how many users you have online at that time. Cache is also a way you can store information on the server. All of these are stored on the server so if you have hundreds of users online at the same time, server memory will be consumed holding all this information. Rule of thumb is to try to be conservative when storing information in these locations. Personally, I rarely use application and also try to limit my use of session to when it makes sense. If I were to write an app that used crystal reports as you are, I would probably use sql to store the paramaters of the report and generate the report from the parameters but it depends entirely on the needs of the user using the app.
You can find a wealth of infomation on this subject on line. Hopefully this will give you some information.
My question is how to best handle temporary data for an session. The scenario is similar to a shopping cart or like a bet slip. While the user is navigating the site and adding items with unique ID's. I'm only interested in the data collected this way if the user wants to commit it.
I'm developing in ASP .Net 3.5 with jQuery,JSON and a MS SQL DB.
As I see it there are a few possible ways to do this.
Perform a full post back to the server. Store every selections, update page controls accordingly.
Send selections via a Ajax request back to the server and update displaying control.
Build all functionality in JavaScript and store all values in a session cookie. Nothing being sent to server until user choose to commit.
I really want to consider performance here but I don't want to end up with 1000's of lines of JavaScript code..
Any suggestions of the best implementation with pro's and con's?
Cheers,
Stefan
Storing things in a session cookie is not a good idea, because that will be sent back to the server with every request. If you could find a way to store the state on the client without using a cookie, then you might have a viable client-centric option, but i can't think of anything portable off the top of my head. There are things in HTML5 and Flash that can do it, but you don't want to go there - yet, in the case of the former, and at all, in the case of the latter.
I'd use AJAX to post back to the server (with graceful degradation to a full post for browsers that can't handle that), then store the information in volatile memory there - ie not in the database. Write it to the database only when you need to. This is very easy to do in Java (you can associate information with the session), so i assume ASP.net has some way to do it too.
All three possibilities look good to me. The question, however, is: how much traffic do you expect?
Each of the options you presented suits better to a given scenario. Let's say you will have A LOT (thousand of thousands) users and not a lot of hardware available then you should probably try to minimize the number of requests to your app and store data in the client as much as possible before sending it to the server.
If it is smaller application then using Session or some other central database storage would be fine.
It all depends on your requirements.