Re: Prevayler + BlockingQueue
Attila Magyar <[email protected]> Thu, 25 Aug 2016 10:46:14 +0200
| Newsgroups | gmane.comp.java.prevayler |
|---|---|
| Message-ID | <CAPKVUJ+o7v_5Vj=ENYxh32cmp-On7g3jXfL56ipiMuYEpPtOcQ@mail.gmail.com> |
--===============3893837341960949884== Content-Type: multipart/alternative; boundary=001a114fae3c3abb66053ae16e19 --001a114fae3c3abb66053ae16e19 Content-Type: text/plain; charset=UTF-8 Thanks for your answers. Yeah, adding a non blocking method could work, but if I have more than one consumers, then either some additional synchronization or polling would be needed. I'm not really satisfied with the solution. An other option I see is making the queue non persistent, and restoring its state manually at startup using some other persistent storage (which is already there). Attila On Wed, Aug 24, 2016 at 6:10 PM, Justin Sampson <[email protected]> wrote: > Right -- you should _never_ do any blocking operations inside a Prevayler > query or transaction, because Prevayler manages its own concurrency. > > In fact, _any_ nontrivial concurrency inside a transaction makes it > nondeterministic anyway, which is not allowed. > > Your TakeDocument should ideally return an Optional<Document> and your > AddDocument should ideally return a boolean, in order to report failure > instead of blocking. Then you can poll by executing each transaction inside > a loop, optionally adding (as Klaus suggested) separate blocking methods > that do not use transactions _and_ do not actually change the state of the > queue but instead simply notify the waiting thread when it might be able to > proceed (which still requires a retry-loop for correctness). > > Cheers, > Justin > > > -----Original Message----- > From: Klaus Wuestefeld [mailto:[email protected]] > Sent: Wednesday, August 24, 2016 6:22 AM > To: Open discussion about the Prevayler project. > Subject: Re: [Prevayler-discussion] Prevayler + BlockingQueue > > Hi Attila, > > Add a WaitForDocument blocking read operation. It waits for a document > but does not take it, so Take will always work immediately. Since > WaitForDocument is blocking, you cannot use a Prevayler Query. You do > it acessing your objects directly. > > Would that work? > > Klaus > > On Wed, Aug 24, 2016 at 8:21 AM, Attila Magyar <[email protected]> > wrote: > > Hi, > > > > I tried to use Prevayler on a Java BlockingQueue in a naive way, and it > > didn't work the way I expected. I guess I see the reason why, but I'm > still > > not sure how should I use it. > > > > Here is an example code I wrote it > > > > https://gist.github.com/zeroflag/8c7333e96ab9b8c8a09fa0a3b08bb907 > > > > There are 2 commands. AddDocument adds a new document to the queue, > > TakeDocument removes a document from the queue. Both operations blocks > the > > current thread, and probably this is the problem. I assume prevayler uses > > locks on each transactions therefore taking document from an empty queue > > blocks other threads from adding a new document. > > > > My goal is to have a simple persistent (blocking) queue. > > > > Is there any simple way to make this work, or what other options do I > have? > > > > thanks > > Attila > > > > > > > > ------------------------------------------------------------ > ------------------ > > > > _______________________________________________ > > To unsubscribe go to the end of this page: > > http://lists.sourceforge.net/lists/listinfo/prevayler-discussion > > _______________________________________________ > > "Databases in Memoriam" -- http://www.prevayler.org > > > > > > -- > Valeu, Klaus. > > ------------------------------------------------------------ > ------------------ > _______________________________________________ > To unsubscribe go to the end of this page: http://lists.sourceforge.net/ > lists/listinfo/prevayler-discussion > _______________________________________________ > "Databases in Memoriam" -- http://www.prevayler.org > > ------------------------------------------------------------ > ------------------ > _______________________________________________ > To unsubscribe go to the end of this page: http://lists.sourceforge.net/ > lists/listinfo/prevayler-discussion > _______________________________________________ > "Databases in Memoriam" -- http://www.prevayler.org > --001a114fae3c3abb66053ae16e19 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Thanks for your answers. Yeah, adding a non blocking metho= d could work, but if I have more than one consumers, then either some addit= ional synchronization or polling would be needed.=C2=A0<div>I'm not rea= lly satisfied with the solution. An other option I see is making the queue = non persistent, and restoring its state manually at startup using some othe= r persistent storage (which is already there).<div><br></div><div>Attila</d= iv></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On= Wed, Aug 24, 2016 at 6:10 PM, Justin Sampson <span dir=3D"ltr"><<a href= =3D"mailto:[email protected]" target=3D"_blank">[email protected]= </a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin= :0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Right -- you shoul= d _never_ do any blocking operations inside a Prevayler query or transactio= n, because Prevayler manages its own concurrency.<br> <br> In fact, _any_ nontrivial concurrency inside a transaction makes it nondete= rministic anyway, which is not allowed.<br> <br> Your TakeDocument should ideally return an Optional<Document> and you= r AddDocument should ideally return a boolean, in order to report failure i= nstead of blocking. Then you can poll by executing each transaction inside = a loop, optionally adding (as Klaus suggested) separate blocking methods th= at do not use transactions _and_ do not actually change the state of the qu= eue but instead simply notify the waiting thread when it might be able to p= roceed (which still requires a retry-loop for correctness).<br> <br> Cheers,<br> Justin<br> <div class=3D"HOEnZb"><div class=3D"h5"><br> <br> -----Original Message-----<br> From: Klaus Wuestefeld [mailto:<a href=3D"mailto:[email protected]">mail@klaus= .pro</a>]<br> Sent: Wednesday, August 24, 2016 6:22 AM<br> To: Open discussion about the Prevayler project.<br> Subject: Re: [Prevayler-discussion] Prevayler + BlockingQueue<br> <br> Hi Attila,<br> <br> Add a WaitForDocument blocking read operation. It waits for a document<br> but does not take it, so Take will always work immediately. Since<br> WaitForDocument is blocking, you cannot use a Prevayler Query. You do<br> it acessing your objects directly.<br> <br> Would that work?<br> <br> Klaus<br> <br> On Wed, Aug 24, 2016 at 8:21 AM, Attila Magyar <<a href=3D"mailto:m.magy= [email protected]">[email protected]</a>> wrote:<br> > Hi,<br> ><br> > I tried to use Prevayler on a Java BlockingQueue in a naive way, and i= t<br> > didn't work the way I expected. I guess I see the reason why, but = I'm still<br> > not sure how should I use it.<br> ><br> > Here is an example code I wrote it<br> ><br> > <a href=3D"https://gist.github.com/zeroflag/8c7333e96ab9b8c8a09fa0a3b0= 8bb907" rel=3D"noreferrer" target=3D"_blank">https://gist.github.com/<wbr>z= eroflag/<wbr>8c7333e96ab9b8c8a09fa0a3b08bb9<wbr>07</a><br> ><br> > There are 2 commands. AddDocument adds a new document to the queue,<br= > > TakeDocument removes a document from the queue. Both operations blocks= the<br> > current thread, and probably this is the problem. I assume prevayler u= ses<br> > locks on each transactions therefore taking document from an empty que= ue<br> > blocks other threads from adding a new document.<br> ><br> > My goal is to have a simple persistent (blocking) queue.<br> ><br> > Is there any simple way to make this work, or what other options do I = have?<br> ><br> > thanks<br> > Attila<br> ><br> ><br> ><br> > ------------------------------<wbr>------------------------------<wbr>= ------------------<br> ><br> > ______________________________<wbr>_________________<br> > To unsubscribe go to the end of this page:<br> > <a href=3D"http://lists.sourceforge.net/lists/listinfo/prevayler-discu= ssion" rel=3D"noreferrer" target=3D"_blank">http://lists.sourceforge.net/<w= br>lists/listinfo/prevayler-<wbr>discussion</a><br> > ______________________________<wbr>_________________<br> > "Databases in Memoriam" -- <a href=3D"http://www.prevayler.o= rg" rel=3D"noreferrer" target=3D"_blank">http://www.prevayler.org</a><br> ><br> <br> <br> <br> --<br> Valeu, Klaus.<br> <br> ------------------------------<wbr>------------------------------<wbr>-----= -------------<br> ______________________________<wbr>_________________<br> To unsubscribe go to the end of this page: <a href=3D"http://lists.sourcefo= rge.net/lists/listinfo/prevayler-discussion" rel=3D"noreferrer" target=3D"_= blank">http://lists.sourceforge.net/<wbr>lists/listinfo/prevayler-<wbr>disc= ussion</a><br> ______________________________<wbr>_________________<br> "Databases in Memoriam" -- <a href=3D"http://www.prevayler.org" r= el=3D"noreferrer" target=3D"_blank">http://www.prevayler.org</a><br> <br> ------------------------------<wbr>------------------------------<wbr>-----= -------------<br> ______________________________<wbr>_________________<br> To unsubscribe go to the end of this page: <a href=3D"http://lists.sourcefo= rge.net/lists/listinfo/prevayler-discussion" rel=3D"noreferrer" target=3D"_= blank">http://lists.sourceforge.net/<wbr>lists/listinfo/prevayler-<wbr>disc= ussion</a><br> ______________________________<wbr>_________________<br> "Databases in Memoriam" -- <a href=3D"http://www.prevayler.org" r= el=3D"noreferrer" target=3D"_blank">http://www.prevayler.org</a><br> </div></div></blockquote></div><br></div> --001a114fae3c3abb66053ae16e19-- --===============3893837341960949884== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------------ --===============3893837341960949884== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion _______________________________________________ "Databases in Memoriam" -- http://www.prevayler.org --===============3893837341960949884==--