Project client, server-side validation, database federated UNIQUE constraint, transaction management.

There is a requirement in the project to publish an activity, record the ID and participant ID of participating in the activity, call the interface, add a record to the collection, and add a record to the transaction table. Finally, according to the results of the return, give different information.

1. If you are currently working on a JSP page, decide if you have participated. After you have participated, the join button is not a point. In case of no participation, the button can be clicked.

2.jsp client plus JS processing, after the button clicked, the button is not point.

3. In the controller, before the business logic begins, Java again determines if it has participated in the activity.

4. In the database, participate in the table (activity ID, participant ID) plus federated unique constraints. Handles non-recurring participation according to the exception.

5. Put the operations of the above tables into one transaction. Avoid situations where participants are repeatedly involved.

Summary: Do not trust the client's authentication, do not believe the network delay (multiple clicks to submit the situation ~~!!), under normal circumstances, the above 1 to 5 any situation can restrict participants to participate in only one activity, but the project on-line in practice, but there is still a record of repeated participation. So only by uniting the above situation together to deal with them.