It seems like it is worthwhile to brush up my knowledge then, this
looks quite hopeful - thanks!
On 24 February 2015 at 10:39, Andrey Antukh wrote:
>
>
> 2015-02-24 10:15 GMT+01:00 Colin Yates :
>>
>> Hi Andrey - thanks for responding. Asciidoctor looks great!
>>
>> I think I understand the sucri
2015-02-24 10:15 GMT+01:00 Colin Yates :
> Hi Andrey - thanks for responding. Asciidoctor looks great!
>
> I think I understand the sucriata approach which serialises access to
> the connection (via the agent). But this doesn't ensure that all
> operations using the connection are done in the same
Hi Andrey - thanks for responding. Asciidoctor looks great!
I think I understand the sucriata approach which serialises access to
the connection (via the agent). But this doesn't ensure that all
operations using the connection are done in the same thread does it (I
didn't think agents were thread-
Hi Colin.
You are talking about suricatta documentation? Is build with asciidoctor.
And, about core.async and transactions, suricatta comes with an async
abstraction that internally uses a clojure agent for serialize all access
to one connection from different threads (managed by core.async inter
Thanks Christian, that looks interesting.
By the way, any idea what tool was used to generate the documentation?
On 23 February 2015 at 21:22, Christian Weilbach
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 23.02.2015 18:20, Colin Yates wrote:
>> Currently each request gets se
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 23.02.2015 18:20, Colin Yates wrote:
> Currently each request gets serviced in its own thread (web
> container) and I am thinking of integrating core.async and I wonder
> how core.async and a JDBC transactional "unit of work" get on.
>
> Conceptual
Currently each request gets serviced in its own thread (web container) and
I am thinking of integrating core.async and I wonder how core.async and a
JDBC transactional "unit of work" get on.
Conceptually, this model (thread-per-request) is trivial however the
problems are well known. Replacing