Multiple Posts

[Irrelevant]

Would it not be a good to screen these out at the database level? Just a simple check before adding a post to check that the same text has not been added to the thread before.

Is there a technical reason this can't be done?

 

Must get the Gigabusa finished

[Site Manager]

Hi Adam,

 

The messages are stored in a field of type "text", hence I can't perform a direct comparison, but would have to use the "like" operator, which I don't think will be that efficient through over 82500 topics, or 706500 replies. So I have another plan.

 

Each post is generated through two pages, the first is post.asp, which determines whether it's a new topic, or a new reply, or an edit of an existing topic or reply and presents you with the fields to input. The second page is post_infoSQL.asp, which checks what you've typed in and then inserts/amends the database record.

 

I believe that most double-posts are as a result of an error somewhere, rather than a deliberate act, so what I'm going to do is generate a random number in post.asp and place it in a field in the form. When post_infoSQL.asp receives the data and has successfully updated the database, this random number will be stored in a session variable. One of the first things that post_infoSQL.asp will do when it is called is to check whether the number passed to it is the same as the number stored in the session variable. If it is, then the data has already been processed, and a suitable error message is displayed, if it isn't then it's probably a new message and will be allowed through.

 

Are there any flaws in my logic?

[Irrelevant]

The messages are stored in a field of type "text", hence I can't perform a direct comparison, but would have to use the "like" operator, which I don't think will be that efficient through over 82500 topics, or 706500 replies.

It wouldn't be all the topics/replies. You would only need to check the topics/replies WHERE the userid = the user submitting the data and the topic was = to whatever topicid is supplied. Thus, you'd only be comparing a few text to whetever number of posts a topic has that have been submitted by a specific user.

 

Are there any flaws in my logic?

Well, yes....I fear there might be. If I was to click a post reply button 5 times (for whatever reason) I'd send 5 identical replies to the same topic. Each would go to post.asp and each will generate a new random number and thus will go through as a non-duplicate. Even if you can get similar logic to work, if you don't use the topicid and usedid of whom ever is posting replies, how will they be able to reply to more than one thread per session?

If you want to avoid database checks, you could use a session object for each user which kept the topicid and the text of their last post. Then, just check this object before adding anything to the database,

e.g.

post.asp does what it does now.

post_infoSQL.asp checks for the existance of a user session object called 'LAST_POST' or something. This would have 2 values, LAST_TOPIC_ID and TEXT. Have it set up to have a short persistence for performance reasons. Now I'm not sure of the asp terminology for session object persistence but I assume it's configurable (I did jsp/java/j2ee and then aspx/C#/Dot.Net)

If LAST_POST exists for a user, check the LAST_TOPIC_ID.

If the LAST_TOPIC_ID matches the topicid of the post that's been submitted, check the TEXT (and do an efficient string comparison method if asp doesn't have one).

If TEXT matches the text of the new post, just ignore it - don't even bother displaying a message.

If the post's not a duplicate, add it to the database and create the LAST_POST session object for the user.

 

As I said, I'm no asp guru but I think my logic's sound. You will have a maximum of 1 small session object for the recently active users who've posted something. These session objects will be cleared up when their persistence runs out.

There may be issues if you're running multiple web servers and a post can be sent to any one of them. However, I'm assuming you're already using session state. If so, I don't see a problem?

 

 

 

 

Must get the Gigabusa finished

[Site Manager]

Hi Adam, thanks for this, it's an interesting solution, and the only downside that I can see is that it may require quite a lot of data to be stored in the session variable.

 

Most of the double posts that we have had have been owing to a bug which cropped up when people were posting to a forum, having gone to that forum via the forumjump boxes. This has now been fixed (as of last night).

 

The other times that double posts have occured is when one of the servers (or the 'internet') has been slow and so the likelihood is that Blatchatters have just clicked the back button and then reposted. The fix applied last night will prevent that from happening too.

 

For a double post to occur now, the back button has to be used, followed by the refresh button. If I find that we still suffer from double posts, it's probably going to be through someone playing silly buggers, in which case I will revisit this.

 

Barry