We have a back end application to manage messages from our clients. We have 4 customer care executives and we want to prevent the situation where the same message can't be opened by two different members, so we would like to do following...
Suppose user1 opened message id 15 and after that user2 opens same message, so we would like to give a alert that 'This message is already opened by user1'. How do we do it?
Create a different table in your database.
When a user opens a message, update the table to show which message has been opened and by which user.
When another user tries to open it, crosscheck the table to see if there is a row for that message. You can then do the appropriate action such as open or warn the user.
You can delete the rows after a given timeout period to allow others to open.
Schema eg
User_id msg_id time_opened
Unfortunately, you can't use sessions since the sesssion is user specific. However, you can employ flatfiles.
To delete the rows, employ a method such as
$timeout_time_in_seconds = 30;
$time = time() - $timeout_time_in_seconds;
$Query= "delete from table where time_opened
Note that depending on the time field, which can be an int, datetime or timestring, additional date formating of the $time variable may be required. However, int will be most convenient due to ease in comparison and subtraction and no formatting.
I'm mobile so pardon any errors. Also that's why I didn't comment but had to edit. Js issues.
What happens is, when the first user clicks, a quick check and update of the database is made.
When the second user tries, the script will detect the first user has already opened by checking the database.
You can count on this to work if the traffic load is low and the number of users trying to access is not too great. And also counting on the fact that the read and insert queries occur in a short time which as you can Guess is faster then two users clicking at the same time. Unless you have another issue, this should work
Simpliest way would be to implement as pessimistic locking at the DB level
http://www.blackwasp.co.uk/PessimisticLocking.aspx
Whatever language you are using should let you check the DB to see if a row is locked or not and send a message on the screen.
You can additionally setup your application with long polling to notify users when the request resource has become available. http://en.wikipedia.org/wiki/Push_technology
Related
I have a script that is written in PHP. It uses MySQL database to store records.
Basically, I have team of users that are making random calls to a different business. I want to add list of phone number in a queue "pool table". The system will need to assign the new call to the user. Now If a user is already working on a phone call I don't want another user to start calling the same number. I need a solution to prevent 2 people having the same record assigned to them. So if phone number 000-000-0000 is assigned to the user X the same record will be skipped and the next one in line get assigned to the next available user.
This table will be accessed a lot so I need a good solution that will prevent 2 people from working on the same record and also not cause system issues.
One way I can think of but looking for a better solution is
open transaction
select a call where record status is available
update that call by changing the status from records available to record pending.
commit transaction.
If the use completed the call then updated with a status of completed otherwise make the record available again.
what are other solution available for me?
Thanks
Without a little more information about the workflow, it's hard to know what to suggest, but it sounds like users are interacting with the application somehow while they are taking calls...true??
If so, you must have some way for the user to alert the system they are ready for a call.
ie...
I just started my shift... Deal me a number.
Or...
Submit notes from last call... click submit and Deal me another number.
In this scenario, it seems like it should pretty easy to just let the users "request" the next number. You could probably just insert the users id on that record so it shows in their queue.
I have a simple and generic internal messaging service on one of my PHP/MySQL sites, with a unique messageID, from, to, subject, message, time, and isRead.
In general, what is the best way to check that a user has new mail?
Should I store a simple binary trigger on the main Users table that gets switched to 1 when anyone sends them a message, and then have the user check for that 1 on every pageload, and if there is one, alert them to the new mail (and set it to 0 whenever they go to their Inbox)? But what if it was spam and we deleted it before the user read it?
Or should I store the messageid of the last message the user read, and then do a check for the latest message and see if it's more recent than the last one that he read, and if so alert him? But then how and where should I store this info?
Is there another, more efficient method considering we would have to check for new messages on every pageload?
If the user goes to his Inbox, it should no longer show him that he has "New Mail" for any of the messages that were in his Inbox at the time he checked it, regardless of whether he's actually clicked to read them or not.
Thanks!
EDIT: Some of my users access my site from very basic phones that don't have cookies or even Javascript, so please keep that in mind.
Best way would be push notification from server, like stackoverflow does, using html sockets.
jquery plugin
But keep in mind that is not supported by all browser, so will need to fall back to ajax polling.
About spam i would suggest only notify user after spam checking if done, if possible.
Your solution to store next to user with set bit sounds right, (also you could store number of new message, instead of bit)
In your users table, store the count of new messages, and update when needed.
AJAX polling can be expensive in serverside (the select count(*) from ... can be expensive when your DB became large, and you need to do it, for example, one check per minute).
If the user just browsing in your website, and have no new messages, you can just skip select more information about messages.
I'm creating a PHP Web application, which would involve:
1) Users opening a record
2) Users making changes to the record
3) Saving changes to the record
Since this is a multi-user application, I want to prevent situations where two users have the same record open at the same time, and one user's changes overwrites the next, preferrably by enforcing some sort of locking method when a record is opened that automatically unlocks when the user navigates away from the page.
By record, you mean SQL records? If so, you could add another column isOpen. Set it to 1 as long as someone else has it open, and in that case, do not serve it to anyone else.
In situations like this, it works best to also implement a timeout mechanism, where a record can be open only for 'x' min before being forcibly closed.
(Edit: This answer is assuming you want to keep a record locked the entire duration a user is viewing the info fetched from the table. If you want to lock a record only for the instant that a read/write operation is occuring on that record, MySQL engines have inbuilt mechanisms for that)
In response to your comment
To make a record accessible to others when the active user navigates away, off the top of my head, I can think of two ways to achieve it:
Allow the timeout mechanism to take care of it. Depending on your scenario, a short enough time window could work fine.
In addition to the timeout, also implement a heartbeat mechanism - an Ajax script on the page polls the server letting it know the page is still open. If the user navigates away, the server recognizes the skipped heartbeat, and unsets the record. In this case, the timeout would still take precedence. So, if the user leaves the window open and walks away, the server would still receive the heartbeat, but when the time window closes, the server unsets the record (despite still receiving heartbeats).
I use a field update_date. When user reads the record I write a cookie with this date. When user updates the record and submits the new data I'am adding WHERE update_date = '$my_escaped_date' AND id = '$the_edited_id' and if mysql_affected_rows is zero I'm showing error message that the edited data is old. It's not perfect as if you edit old data you must reenter it, but it does the job.
A locking method is exactly what is available in mysql:
http://dev.mysql.com/doc/refman/5.0/en/lock-tables.html
It's not automatic but it allows you to lock a table, do stuff and then unlock it again.
Be carefull tho' that the system does not become locked up if you forget to unlock a table or a user takes a long time to change something and you only unlock it when that user submits the form.
A better way might be to read data from the table and upon submission of the form, check to see if the data has not been altered. If it has you can notify the user of the changes and other wise you can lock the table, perform the changes and unlock it again.
You can add a field in_use to the records table,
when a user open that record update its value to 1 and when he saves it
update it back to 0.
If the value is 1 - the record is locked and won't be opened for other users.
i m creating two table(in mysql) named
table_temp_guest
table_temp_order
now if a guest enters then we save his personal information in this first table and if he purchase something from any stall ,it saved as a temporary order in table_temp_order.
now my question is :
i m using session id, so when user goes to logout( without checkout) then
i delete his information(personal and order) from both table )using session id,
BUT if he close the browser, or does not go to checkout(any reson) then how
to delete his information from both tables
please suggest me how to do this?
additional question:
is there any other way to do this whole process by some other manner.
You can't detect when a user closes the browser or types in a new address. You basically need to have a "timeout" facility like the rest of the websites have.
There is a window.onunload event that you can detect with javascript, but it's not universally supported, and it detects window closes, not browser closes.
Your best resolution is probably going to be tracking the session_id and last accessed date. Re-update the table's last_accessed_date on every page load, and delete everything that's older than a few hours.
A timeout would be the best method.
Record the last active time in the guest table. Have a cron job running periodically on the web server cleaning up sessions that exceed the maximum time that you wish to allow.
Be careful about the amount of time that you allow. You have to allow for slow users and dropped connections.
If you're using session_id() anyway (I guess this is what you mean by session id), just use php sessions. PHP automatically invalidates them for you and you don't need those two tables (you can store everything you need in $_SESSION).
There is no way to check if the broswer wasn't closed you could rely on.
If you don't want to change the way your project works now, just add a created field to the tables and set it to the current time() whenever you're "seeing" the specific user. Then set up a cronjob which deletes all records from this table which are older than a specific timeout.
Also you can try to have a script that would run on the client side and ping the server so that you know if the script has not pinged for a while, the user closed the browser. That being said, I would agree with the previous posters, a timeout/ cleanup procedure would be best.
For that you would add a ModifiedDate field to your tables, you can set it as an "ON UPDATE" field for ease of use, then just delete all records that have an ModifiedDate field of older then several hours.
I am building a social network site in PHP/MySQL/jQuery. Once a user is logged into my site, I would like to query the DB and get an admin announcement if one exist. This will be a message box that shows on the page to all users but it will have an X to click on it and not show it ever again until the admin post a new announcement message. So if you never click the X and there is announcement messages that exist in the db, it will always show this message box on your page, however if you did cli9ck the X to close the box, then you come back to the page it will not be there, unless there is a new admin message posted.
I know there is several ways of doing this but I am looking for the most efficient way.
One idea I have, if I add an extra mysql field onto the user's table "admin_message" and mark it as 0, then when I post a new admin message it will change the record for every user to 1, if admin message is set to 1 then it shows on user's page. Then when the user clicks the X to hide the box, it will update there user table row and chnage the value back to 0.
Another idea I have is to use cookie's to check if a user has chosen to hide a message, i think this would be faster but maybe not as good, since user can log in with differnt computers and if a new message is shown, they may not see it right away.
So I am just wondering if it is a bad idea to use the extra database field? If I had 1,000,000 users, when I posted a new admin message, then I would need to update 1,000,000 rows to make sure everyone can see the message. Is there a better way? Also once a user logs into my site I will use a session to store the value of them seeing or hiding the message instead of looking at the DB on every page load.
UPDATE
Sorry I think my post might of been a little confusing or not clear on what exactly I meant because most the responses are catered to a message system which this is not anything close to.
Forget the message word please I will try to explain with a different word. Let's say there is 1 admin on the site, that is the only admin who can post a message to users to see. The users will only see 1 message, if there is 2352345234 messages posted over the lifetime of the site, it won't matter, they will only see 1 message, the newest message.
Now some users who log in and see this message "div" on the page might get tired of looking at it, so they will be able to hide it from ever showing again.
It will be as simple as a yes or no for showing this message on there page.
However if I decide I need to post a new admin message for all users to see, then even a user who chose to hide and not show the admin message will still see it again until they choose to never see it again.
Two simple solutions are as follows:
Good: Check the users cookie, if it contains a flag indicating the message was displayed don't display the message, otherwise display it. When the user closes it, update the cookie. Pros: absolutely simple. Cons: The user might see the same message twice depending on if they clear their cookies or log in from another machine.
Better: Store a flag in the database somewhere (you can store it in the admin user table for now, and down the line break it out into another table). When the user logs in, 1) save this flag to the user's cookie or session, 2) update the database, 3) decide whether the message needs to be shown. When the user closes the message, updare the cookie/session and DB. Pros: User never gets shown the message twice. Cons: slightly more involved as you need to maintain the flag in the db.
Implementation details:
For the flag, you could use a message id as suggested already, or more than likely you are already retaining the user's last login timestamp and could use that.
Every user could have a last_message_seen, so you have to query "new" messages (message_id > last_message_seen) for your user. If you [X] close (or timeout), then your javascript can check new messages and so on...
The other idea is to have that last message seen number in the javascript environment, but in that case it will be reseted (recalculated) when you refresh/abandon the page, and if it's not on the DB your user can miss messages inserted between last page load and this refresh.
Or... it can be in the Session, so you don't miss any. When you logon, the number is reseted to some "normal" number, let's say: last message, or message after (now - 1h), or whatever...
You are keeping a login time for the user right? Like a last_login datetime?
So get all messages where date_created >= last_login. Display them, then update the last_login time to now().
I would use idea #1. I wouldn't use a bool-field to check whether the user has read the message, I'd use a datetime-field, with some default value. If field == default, unread. When read, set field NOW().
That way you know aproximately how fast your users read the message.
EDIT:
after your edit, I'd still use the same mechanism. The message needs a field to find out whether or not is read. If the users clicks the X (to close), update the db and mark the message as read.
If the admin posts a new message, this will popup.
You also need a creation-datetime for your messahe, cause if a user did not close the previous message, and the admin posts a new one, only the latest message can be shown.
EDIT2:
In reply to this comment:
Even if a user missed am message, only
the newest should be shown. Maybe I am
misunderstaning but it sounds like you
are saying to basicly mark a message
read 100,000 times is 100,000 users
click the X and I think it should be
more on the user table, show or do not
show message box, not on an individual
basis
something is not locigal in your theory. You want to save the "show/don't show" as a setting, but you want to show the message anyway. How do you know when to overrule the usersetting and when not without remembering whether the system showed the message to the user?
Even if you want to just show it once, you'll need a field in the database (on message-level) to store whether the system showed the message to the user or not.
I'd recommend having a admin_message_queue table. It'll have a message body, a user ID, and a message ID. When you post a new admin message it'll add a record for every admin user to that table. Then when they log in you simply select all admin_message_queue rows where user ID = the logged in user.
To get rid of the message you'd just have the close button trigger an AJAX callback to a method on the server that takes the message ID. That method will delete from admin_message_queue where message ID = the one posted in and user ID = the user ID from the session. That way a user can't delete messages for someone else.
Doing it this way saves you from having to keep around rows of viewed messages. Why toggle a bit to hide it for someone? You'll end up keeping around lots of data that's no longer used.
Updated after question update:
Sorry I thought you were trying to show messages to just admins. You could keep this same logic for displaying the most recent message to all users, too. Simply have a table with a userID, message text. Whenever you post a message it will go through and overwrite the message text for all people that have records still existing (people who haven't hidden the message) and add rows for other people. When they hide the message delete that user's row.