Re: Lock.lock("info")..

--===============5963792556329919490==
Content-Type: multipart/alternative; boundary="000000000000ae3fe405d15d48e8"

--000000000000ae3fe405d15d48e8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Yes, that was the holder that I was referring to.

I understand that Lock is not a repo but a small String that captures the
reason for acquiring the lock would have helped. I have it already
addressed; so just wanted to check if there is a possibility to have that
API so that we don't have to create similar holders that capture the reason
as the reasons are dynamic in nature.

Do appreciate the follow ups! We can close this thread.

Thanks & Regards,
-Kedar.

On Mon, 22 Nov 2021 at 14:51, David Holmes <[email protected]> wrote=
:

> Hi Kedar,
>
>
>
> I added back the c-I list.
>
>
>
> So IIUC you want to store information about the last operation with the
> lock, so that next time if you can=E2=80=99t get it (?) because teardown =
has not
> finished, you could query the lock to see what the previous operation was=
,
> and report that back. In other words your lock is the only common object
> you have for different messages in the same session so you want to use it
> to channel the data through. In such a situation I would expect you to ma=
p
> a session id to a Session object which includes the lock and any other da=
ta
> about the session you might want to track. If that is the =E2=80=9CHolder=
=E2=80=9D that you
> previously referred to then that is the best way to do this IMO.
>
>
>
> It isn=E2=80=99t the job of a Lock to act as a data repository, so I woul=
d not
> consider adding the kind of API you have suggested.
>
>
>
> Cheers,
>
> David
>
>
>
> *From:* Kedar C. Raybagkar <[email protected]>
> *Sent:* Monday, 22 November 2021 6:18 PM
> *To:* [email protected]
> *Subject:* Re: [concurrency-interest] Lock.lock("info")..
>
>
>
> Consider a simple servlet.
>
>
>
> This servlet creates an AsyncFuture and waits for say 3 seconds max befor=
e
> sending the response out to the caller. If the response is generated with=
in
> 3 seconds it is sent out, else we send a long running response (with
> reference to the future) to the caller. The caller if receives the respon=
se
> it displays it else if it finds a long running response then again calls
> the server by passing the reference id.
>
>
>
> Now we have this future execute the job in two distinct ways. #1 waits
> till the entire operation is complete and #2 with no wait for the tear do=
wn
> process.
>
>
>
> Teardown process serializes some data and it takes some time before it
> completes but the response is already generated and can be sent to the
> caller.
>
>
>
> In case of #2 what we do is on the queue we push the response early on an=
d
> then continue to do teardown. The caller waits on the queue and as soon a=
s
> the response is received it returns that to the caller.
>
>
>
> Usually the user takes time to send further requests to the server and in
> normal scenarios the tear down is finished by the time the next request
> comes. When the next request comes to the server we have to ensure that t=
he
> prior requests teardown is complete. So we have used Lock to latch on and
> release it once teardown is complete. The latch is acquired as per the
> session (UUID reference) so that when the next request comes it gets the
> same latch and waits on the latch to be released.
>
>
>
> As we need to keep all these Locks in a map based on the UUID (session
> identifier) we need to hold on to the encapsulated lock DTO that holds th=
e
> purpose of what was being done before.
>
>
>
> Hope I am able to explain it to your satisfaction.
>
>
>
> Thanks & Regards,
>
>
>
>
>
> On Mon, 22 Nov 2021 at 12:01, David Holmes <[email protected]>
> wrote:
>
> Why do you need a Holder object for the lock and condition? The lock and
> condition belong in the object whose state they are guarding and
> interacting with. If you are using external synchronization you wont have
> an encapsulated lock/condition but the code using the lock/condition has =
to
> know what it is actually dealing with and so that code can report that
> information.
>
>
>
> David
>
>
>
> *From:* Kedar C. Raybagkar <[email protected]>
> *Sent:* Monday, 22 November 2021 4:23 PM
> *To:* [email protected]
> *Cc:* [email protected]
> *Subject:* Re: [concurrency-interest] Lock.lock("info")..
>
>
>
> Thank you, David.
>
>
>
> That is what I have been doing but instead of having to encapsulate into =
a
> separate holder object I thought it might be a good idea to have some API
> directly available. As encapsulation also results in having a Value Objec=
t
> with hashcode and equals being overridden and then keeping them in a map
> with thread ids. This is already within the lock; just an additional stri=
ng
> or object parameter may help solve the problem.
>
>
>
> Regards,
>
> -Kedar.
>
>
>
> On Mon, 22 Nov 2021 at 11:28, David Holmes <[email protected]>
> wrote:
>
> Hi Kedar,
>
>
>
> The Lock and Condition should be encapsulated inside the object that need=
s
> them, and that object can provide whatever additional information the
> callers needs on its own methods.
>
>
>
> Cheers,
>
> David
>
>
>
> *From:* Concurrency-interest <[email protected]>=
 *On
> Behalf Of *Kedar C. Raybagkar via Concurrency-interest
> *Sent:* Monday, 22 November 2021 3:43 PM
> *To:* [email protected]
> *Subject:* [concurrency-interest] Lock.lock("info")..
>
>
>
> Hi,
>
>
>
> Can we have something API where we can provide why we have acquired a loc=
k
> so that when waiting on a condition if timed out we can fetch the info an=
d
> return it to the caller?
>
>
>
> Regards,
>
> -Kedar.
>
>

--000000000000ae3fe405d15d48e8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Yes, that was the holder that I was referring to.<div><br>=
<div>I understand that Lock is not a repo but a small String that captures =
the reason for acquiring the lock would have helped. I have it already addr=
essed; so just wanted to check if there is a possibility=C2=A0to have that =
API so that we don&#39;t have=C2=A0to create similar holders that capture t=
he reason as the reasons are dynamic in nature.</div><div><br></div><div>Do=
 appreciate the follow ups! We can close this thread.</div><div><br></div><=
div>Thanks &amp;=C2=A0Regards,</div><div>-Kedar.</div></div></div><br><div =
class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, 22 Nov =
2021 at 14:51, David Holmes &lt;<a href=3D"mailto:[email protected]"=
>[email protected]</a>&gt; wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex"><div lang=3D"EN-AU" style=3D"overflow-wrap: break-=
word;"><div class=3D"gmail-m_9202285258186441888WordSection1"><p class=3D"M=
soNormal"><span>Hi Kedar,<u></u><u></u></span></p><p class=3D"MsoNormal"><s=
pan><u></u>=C2=A0<u></u></span></p><p class=3D"MsoNormal"><span>I added bac=
k the c-I list.<u></u><u></u></span></p><p class=3D"MsoNormal"><span><u></u=
>=C2=A0<u></u></span></p><p class=3D"MsoNormal"><span>So IIUC you want to s=
tore information about the last operation with the lock, so that next time =
if you can=E2=80=99t get it (?) because teardown has not finished, you coul=
d query the lock to see what the previous operation was, and report that ba=
ck. In other words your lock is the only common object you have for differe=
nt messages in the same session so you want to use it to channel the data t=
hrough. In such a situation I would expect you to map a session id to a Ses=
sion object which includes the lock and any other data about the session yo=
u might want to track. If that is the =E2=80=9CHolder=E2=80=9D that you pre=
viously referred to then that is the best way to do this IMO.<u></u><u></u>=
</span></p><p class=3D"MsoNormal"><span><u></u>=C2=A0<u></u></span></p><p c=
lass=3D"MsoNormal"><span>It isn=E2=80=99t the job of a Lock to act as a dat=
a repository, so I would not consider adding the kind of API you have sugge=
sted.<u></u><u></u></span></p><p class=3D"MsoNormal"><span><u></u>=C2=A0<u>=
</u></span></p><p class=3D"MsoNormal"><span>Cheers,<u></u><u></u></span></p=
><p class=3D"MsoNormal"><span>David<u></u><u></u></span></p><p class=3D"Mso=
Normal"><span><u></u>=C2=A0<u></u></span></p><div style=3D"border-right:non=
e;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225)=
;padding:3pt 0cm 0cm"><p class=3D"MsoNormal"><b><span lang=3D"EN-US">From:<=
/span></b><span lang=3D"EN-US"> Kedar C. Raybagkar &lt;<a href=3D"mailto:ke=
[email protected]" target=3D"_blank">[email protected]</a>&gt=
; <br><b>Sent:</b> Monday, 22 November 2021 6:18 PM<br><b>To:</b> <a href=
=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a><br><b>S=
ubject:</b> Re: [concurrency-interest] Lock.lock(&quot;info&quot;)..<u></u>=
<u></u></span></p></div><p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p><div=
><p class=3D"MsoNormal">Consider a simple servlet.<u></u><u></u></p><div><p=
 class=3D"MsoNormal"><u></u>=C2=A0<u></u></p></div><div><p class=3D"MsoNorm=
al">This servlet creates an AsyncFuture and waits for say 3 seconds max bef=
ore sending the response out to the caller. If the response is generated wi=
thin 3 seconds it is sent out, else we send a long running response (with r=
eference to the future) to the caller. The caller if receives the response =
it displays it else if it finds a long running response then again calls th=
e server by passing the reference id.<u></u><u></u></p></div><div><p class=
=3D"MsoNormal"><u></u>=C2=A0<u></u></p></div><div><p class=3D"MsoNormal">No=
w we have this future execute the job in two distinct ways. #1 waits till t=
he entire operation is complete and #2 with no wait for the tear down proce=
ss.<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=C2=A0<u></u>=
</p></div><div><p class=3D"MsoNormal">Teardown process serializes some data=
 and it takes some=C2=A0time before it completes but the response is alread=
y generated and can be sent to the caller.<u></u><u></u></p></div><div><p c=
lass=3D"MsoNormal"><u></u>=C2=A0<u></u></p></div><div><p class=3D"MsoNormal=
">In case of #2 what we do is on the queue we push the response early on an=
d then continue to do teardown. The caller waits on the queue and as soon a=
s the response=C2=A0is received=C2=A0it returns that to the caller.<u></u><=
u></u></p></div><div><p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p></div><=
div><p class=3D"MsoNormal">Usually the user takes time to send further requ=
ests to the server and in normal scenarios the tear down is finished by the=
 time the next request comes. When the next request comes to the server we =
have to ensure that the prior requests teardown is complete. So we have use=
d Lock to latch on and release it once teardown is complete. The latch is a=
cquired as per the session (UUID reference) so that when the next request c=
omes it gets the same latch and waits on the latch to be released.<u></u><u=
></u></p></div><div><p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p></div><d=
iv><p class=3D"MsoNormal">As we need to keep all these Locks in a map based=
 on the UUID (session identifier) we need to hold on to the encapsulated lo=
ck DTO that holds the purpose of what was being done before.<u></u><u></u><=
/p></div><div><p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p></div><div><p =
class=3D"MsoNormal">Hope I am able to explain it to your satisfaction.<u></=
u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p></di=
v><div><p class=3D"MsoNormal">Thanks &amp; Regards,<u></u><u></u></p></div>=
<div><p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p></div></div><p class=3D=
"MsoNormal"><u></u>=C2=A0<u></u></p><div><div><p class=3D"MsoNormal">On Mon=
, 22 Nov 2021 at 12:01, David Holmes &lt;<a href=3D"mailto:davidcholmes@aap=
t.net.au" target=3D"_blank">[email protected]</a>&gt; wrote:<u></u><=
u></u></p></div><blockquote style=3D"border-top:none;border-right:none;bord=
er-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6=
pt;margin-left:4.8pt;margin-right:0cm"><div><div><p class=3D"MsoNormal">Why=
 do you need a Holder object for the lock and condition? The lock and condi=
tion belong in the object whose state they are guarding and interacting wit=
h. If you are using external synchronization you wont have an encapsulated =
lock/condition but the code using the lock/condition has to know what it is=
 actually dealing with and so that code can report that information.<u></u>=
<u></u></p><p class=3D"MsoNormal">=C2=A0<u></u><u></u></p><p class=3D"MsoNo=
rmal">David<u></u><u></u></p><p class=3D"MsoNormal">=C2=A0<u></u><u></u></p=
><div style=3D"border-right:none;border-bottom:none;border-left:none;border=
-top:1pt solid rgb(225,225,225);padding:3pt 0cm 0cm"><p class=3D"MsoNormal"=
><b><span lang=3D"EN-US">From:</span></b><span lang=3D"EN-US"> Kedar C. Ray=
bagkar &lt;<a href=3D"mailto:[email protected]" target=3D"_blank">k=
[email protected]</a>&gt; <br><b>Sent:</b> Monday, 22 November 2021 =
4:23 PM<br><b>To:</b> <a href=3D"mailto:[email protected]" target=3D"_blank"=
>[email protected]</a><br><b>Cc:</b> <a href=3D"mailto:concurrency-interest@=
cs.oswego.edu" target=3D"_blank">[email protected]</a><br>=
<b>Subject:</b> Re: [concurrency-interest] Lock.lock(&quot;info&quot;)..</s=
pan><u></u><u></u></p></div><p class=3D"MsoNormal">=C2=A0<u></u><u></u></p>=
<div><div><p class=3D"MsoNormal">Thank you, David.<u></u><u></u></p></div><=
div><p class=3D"MsoNormal">=C2=A0<u></u><u></u></p></div><div><p class=3D"M=
soNormal">That is what I have been doing but instead of having to encapsula=
te=C2=A0into a separate holder object I thought it might be a good idea to =
have some API directly available. As encapsulation=C2=A0also results in hav=
ing a Value Object with hashcode and equals being overridden and then keepi=
ng them in a map with thread ids. This is already within the lock; just an =
additional string or object parameter may help solve the=C2=A0problem.<u></=
u><u></u></p></div><div><p class=3D"MsoNormal">=C2=A0<u></u><u></u></p></di=
v><div><p class=3D"MsoNormal">Regards,<u></u><u></u></p></div><div><p class=
=3D"MsoNormal">-Kedar.<u></u><u></u></p></div></div><p class=3D"MsoNormal">=
=C2=A0<u></u><u></u></p><div><div><p class=3D"MsoNormal">On Mon, 22 Nov 202=
1 at 11:28, David Holmes &lt;<a href=3D"mailto:[email protected]" ta=
rget=3D"_blank">[email protected]</a>&gt; wrote:<u></u><u></u></p></=
div><blockquote style=3D"border-top:none;border-right:none;border-bottom:no=
ne;border-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin:5p=
t 0cm 5pt 4.8pt"><div><div><p class=3D"MsoNormal">Hi Kedar,<u></u><u></u></=
p><p class=3D"MsoNormal">=C2=A0<u></u><u></u></p><p class=3D"MsoNormal">The=
 Lock and Condition should be encapsulated inside the object that needs the=
m, and that object can provide whatever additional information the callers =
needs on its own methods.<u></u><u></u></p><p class=3D"MsoNormal">=C2=A0<u>=
</u><u></u></p><p class=3D"MsoNormal">Cheers,<u></u><u></u></p><p class=3D"=
MsoNormal">David<u></u><u></u></p><p class=3D"MsoNormal">=C2=A0<u></u><u></=
u></p><div style=3D"border-right:none;border-bottom:none;border-left:none;b=
order-top:1pt solid rgb(225,225,225);padding:3pt 0cm 0cm"><p class=3D"MsoNo=
rmal"><b><span lang=3D"EN-US">From:</span></b><span lang=3D"EN-US"> Concurr=
ency-interest &lt;<a href=3D"mailto:[email protected].=
edu" target=3D"_blank">[email protected]</a>&gt; <=
b>On Behalf Of </b>Kedar C. Raybagkar via Concurrency-interest<br><b>Sent:<=
/b> Monday, 22 November 2021 3:43 PM<br><b>To:</b> <a href=3D"mailto:concur=
[email protected]" target=3D"_blank">[email protected]=
ego.edu</a><br><b>Subject:</b> [concurrency-interest] Lock.lock(&quot;info&=
quot;)..</span><u></u><u></u></p></div><p class=3D"MsoNormal">=C2=A0<u></u>=
<u></u></p><div><p class=3D"MsoNormal">Hi,<u></u><u></u></p><div><p class=
=3D"MsoNormal">=C2=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">Ca=
n we have something API where we can provide why we have acquired a lock so=
 that when waiting on a condition if timed out=C2=A0we can fetch the info a=
nd return it to the caller?<u></u><u></u></p></div><div><p class=3D"MsoNorm=
al">=C2=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">Regards,<u></=
u><u></u></p></div><div><p class=3D"MsoNormal">-Kedar.<u></u><u></u></p></d=
iv></div></div></div></blockquote></div></div></div></blockquote></div></di=
v></div></blockquote></div>

--000000000000ae3fe405d15d48e8--

--===============5963792556329919490==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Concurrency-interest mailing list
[email protected]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

--===============5963792556329919490==--