<p>User A logs into a ticket management system to edit content on "SomePage.aspx"</p>

<p>User B logs in 30 seconds later to edit the same ticket on "SomePage.aspx"</p>

<p>What are some of the best known practices(in a 3-tier architecture) for notifying each of the users that someone else is modifying the same content?  </p>

In a request/response system like HTTP, there isn't much of a concept of what a user is currently doing. You could notify them that someone else opened the ticket for edit "within the last two minutes" (or even prevent them from opening it in such a case) but user A could edit for half an hour - unless you prohibit that as well. You could keep a note of the fact that you believe user A has effectively "got" the item for edit, but with a web app there's nothing to stop the user from just walking away from the computer and never either saving/canceling.
Before thinking about the technological solutions, I suggest thinking about the technological
restrictions
(the asynchronous and request/response nature of the web, basically) and work out the desired behaviour. Some common behaviours are:
First edit wins (tell second editor that their changes have been rejected, basically)
Second edit wins (overwrite first edit - it's too late to tell the first editor)
Merge (can be insanely difficult and/or impossible, depending on the content). This may be automatic or manual (on the part of the second editor).
Prevent a second person from editing while you think a first person may be editing (rarely appropriate for web apps due to the issue mentioned in the first paragraph)