Конечно все зависит от задачи, но вот одно соображение:
Разные сессии изолированы друг от друга и не видят незакоммиченных изменений друг друга. Если это не проблема - хорошо.

И еще, мне кажется что иметь несколько потоков с сессией в каждом - это лишнее. Возможно лучше иметь один поток, работающий с БД и получающий задания от клиентских потоков, которые ставяться ему в очередь. Возможно.

Так как у тебя прога уже написана и возможно сильно править ее нет желания - тогда наверно лучше использовать несколько сессий - не будет гемора с доступом к глобальной, в противном случае, сессии. Не надо будет критические секции раскидывать и все такое. Если работа идет через ADO, то это даже не слишком накладно будет из-за пулинга сессий.

Проблем с передачей сессии потокам не возникло, но возникла проблема с одновременным обращением к сессии нескольких потоков.
Что там с критическими секциями?

Доступ к общему ресурсу (сессии) надо защищать. Нельзя давать одновременно работать с сессией двум потокам - эффект непредсказуем. Собственно работают общие правила многопоточности и шаренных ресурсов.



Подскажите, как сделать, чтобы один поток ждал другого.

Используй примитивы синхронизации - крит. секции, мьютексы, ивенты,...
Если функции потоков одинаковы, то перед тем как обратиться к сессии - войди в крит секцию, закончил работать - выйди из нее.

4 функции
InitializeCriticalSection
Delete...
Enter... - вход
Leave...- выход

и еще Try... варианты.