Question

I have one question regarding trigger.
The scenario is like this

Create Procedure
begin
    Insert into XYZ (a) values (b)
end

Now i have placed the trigger on INSERT – AFTER on table XYZ.
In that trigger there is business logic which takes 2-3 seconds to execute it, business logic is performed against other database table not on the XYZ table

So what i need to confirm here that once INSERT is been done, then the table XYZ will be ready to do insert for another records or it will be locked until the trigger is completed?

EDIT

I have done some more research on this issue and explain it below
In the INSERT – TRIGGER, i have put the my business logic and also below line

WAITFOR DELAY '00:01'

Now when i try to execute the above SP, the SP was not completed for 1 minues (as i have specified the delay of 1 minute in the trigger) and table XYZ was also locked during this period.

So this brings me to the conclusion that trigger does LOCKS the table even if you are not using the same table in the trigger. Am i right? Does anyone has different opinion here?

Answer 1

The question and answer linked to by @Hallainzil show one approach:

• Wrap all table INSERTs and UPDATEs into Stored Procedures
• The SP can then complete the additional Business Logic without maintaining a lock

There is also another approach which is slightly messier in several ways, but also more flexible in many ways:

• Keep a record of which fields have been INSERTED or UPDATED
• Have an agent job fire repeatedly or overnight to process those changes

You may use a trigger to keep that record. Maybe with a LastModifiedTime field, or a hasBeenProcessed field, or even a separate tracking table. It can be done in many ways, and is relatively light weight to maintain (none of the business logic happens yet).

This releases your table from any locks as quickly as possible. It also means that you are able to deal with logins that have the ability to write directly to your table, circumventing your Stored Procedures.

The down side is that your INSERTS/UPDATES and your business logic are being processed Asynchronously. Your other SQL code may need to check whether or not the business logic ha sbeen completed yet, rather than just assuming that both the INSERT and the Business Logic always happen atomically.

So, yes, there are ways of avoiding this locking. But you introduce additional constraints and/or complexity to your model. This is by no means a bad thing, but it needs to be considered within your overall design.