Persistent communication session inside sqlclr proc?

I suspect this is very poor design but I've been asked to research this: can I maintain a persistent communication session inside an sqlclr proc? (tcp/binary packets)

The process has to maintain very high throughput - setting up and tearing down a connection on each transaction is cost prohibitive. For TCO and deployment reasons it is preferable not to have a separate windows service etc that accepts requests from inside the clr proc. Is there the luxury of an alternative integrated into the database?

DONT DO THIS, stored procedures are not windows services. And i believe SQL Server monitors for long running CLR threads and will auto-suspend them. There is some bits and pieces about this in BOL2005.|||Thanks Derek - I have all the ammunition I need know to make an alternate design proposal. I think we've all seen in the past what happens when database servers are used for anything else than a persistence sink and transaction/report processor. Hardware is just too cheap to misuse platforms like this.|||

if you are satisfied please mark an answer.

Thanks,

"D"

sql

Permissions needed to run SSIS Package

If one of our SSIS packages fails because of a communication problem with the backend, and the DBA is not available, my boss wants another individual (probably a senior programmer but not an "sa" type) to be able to re-run the job.

What is the "right" way to do this under SSIS\ sql 2005?

TIA,

barkingdog

this link might help: http://support.microsoft.com/kb/918760/en-us