Well, it's just common way how you can save the connection related
state.
WBR,
Alexey.
On Aug 21, 2008, at 14:07 , Survivant wrote:
> doing this is when we want to process something and it's not
> completed, so we put in back in the context and reprocess it later ?
> ----- Original Message -----
> From: Oleksiy Stashok
> To: users_at_grizzly.dev.java.net
> Sent: Thursday, August 21, 2008 7:42 AM
> Subject: Re: attaching user data to GrizzlyWorkerThread
>
> Ahoj :)
>
> actually there is way...
>
> Inside your filter please do following:
>
> AttributeHolder connectionAttrs =
>
> ctx.getAttributeHolderByScope(AttributeScope.CONNECTION);
> if (connectionAttrs == null) {
> WorkerThread workerThread = (WorkerThread)
> Thread.currentThread();
> // Detach the current Thread data.
> ThreadAttachment threadAttachment =
> workerThread.getAttachment();
> // Attach it to the SelectionKey so the it can be resumed
> latter.
> key.attach(threadAttachment);
> connectionAttrs =
> ctx.getAttributeHolderByScope(AttributeScope.CONNECTION);
> }
>
> connectionAttrs.get/set
>
> Hope this will help.
>
> WBR,
> Alexey.
>
> On Aug 20, 2008, at 16:42 , hsn_at_sendmail.cz wrote:
>
>> > WorkerThread is designed to not hold on to State inbetween
>> different
>> > Requests.
>> Are there plans to add this functionality? i think i could soubmit
>> patch which will adds
>> Context.AttributeScope.WORKER, i want to use this for pooling JDBC
>> connections.
>
>