Actors-Transaction

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Actors-Transaction

thomas.kuehner
Which is the easiest way to meet the following requirements. Imagine  
there are bank accounts where money is transfered between them.  
Additionally, I want to use the actor model, so that each bank account  
is represented by one actor. So my actual question is, what is the  
easiest way to ensure atomic message processing
over severall actors with GPars?

best regards
Thomas Kühner


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Actors-Transaction

Dierk König
Hi Thomas,

the typical misconception is to model the entities (here: bank accounts) as actors where you should rather model the function (here: the transfer) as an actor (or as an dataflowoperator).

With the second approach, you get atomicity by design.

cheers
Dierk


Am 12.08.2013 um 08:35 schrieb [hidden email]:

> Which is the easiest way to meet the following requirements. Imagine there are bank accounts where money is transfered between them. Additionally, I want to use the actor model, so that each bank account is represented by one actor. So my actual question is, what is the easiest way to ensure atomic message processing
> over severall actors with GPars?
>
> best regards
> Thomas Kühner
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Actors-Transaction

thomas.kuehner
Thank you for the fast reply. I realize, my question was perhaps a bit  
misleading. I want to know if it is possible with GPars Actors to  
process messages in a coordinated way, in other words a transaction  
across several actors. If yes, what would the easiest approach. I  
don't have any explicit use case at the moment. Actually, I compare  
concurrency frameworks and want to figure out if this is possible with  
GPars Actors.

Zitat von Dierk König <[hidden email]>:

> Hi Thomas,
>
> the typical misconception is to model the entities (here: bank  
> accounts) as actors where you should rather model the function  
> (here: the transfer) as an actor (or as an dataflowoperator).
>
> With the second approach, you get atomicity by design.
>
> cheers
> Dierk
>
>
> Am 12.08.2013 um 08:35 schrieb [hidden email]:
>
>> Which is the easiest way to meet the following requirements.  
>> Imagine there are bank accounts where money is transfered between  
>> them. Additionally, I want to use the actor model, so that each  
>> bank account is represented by one actor. So my actual question is,  
>>  what is the easiest way to ensure atomic message processing
>> over severall actors with GPars?
>>
>> best regards
>> Thomas Kühner
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>   http://xircles.codehaus.org/manage_email
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>




---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Actors-Transaction

Russel Winder-3
On Mon, 2013-08-12 at 14:38 +0200, [hidden email] wrote:
> Thank you for the fast reply. I realize, my question was perhaps a bit  
> misleading. I want to know if it is possible with GPars Actors to  
> process messages in a coordinated way, in other words a transaction  
> across several actors. If yes, what would the easiest approach. I  
> don't have any explicit use case at the moment. Actually, I compare  
> concurrency frameworks and want to figure out if this is possible with  
> GPars Actors.

I think the very concept of a "transaction over several actors" is
anathema to the whole idea of actors, it doesn't matter which framework
is being used. An actor system is a system founded on asynchronous
messaging and behaviour. Transactions would require global synchronous
messaging and locking, something at the opposite end of computational
models.

Dataflow (or CSP) could in principle allow for synchronous behaviour of
multiple operators if there was a global clock since activation of an
operator is dependent on message reception.

Of course having said the above I can envisage realizing the dataflow
idea with actors, but it would nonethless rely on a global clock.

So basically no! :-)

--
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:[hidden email]
41 Buckmaster Road    m: +44 7770 465 077   xmpp: [hidden email]
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Actors-Transaction

Paolo Di Tommaso
I think Thomas is comparing Gpars Actors to Akka, which supports transactions over the actor model. 


Just my 2 cents.

Cheers,
Paolo



On Mon, Aug 12, 2013 at 8:18 PM, Russel Winder <[hidden email]> wrote:
On Mon, 2013-08-12 at 14:38 +0200, [hidden email] wrote:
> Thank you for the fast reply. I realize, my question was perhaps a bit
> misleading. I want to know if it is possible with GPars Actors to
> process messages in a coordinated way, in other words a transaction
> across several actors. If yes, what would the easiest approach. I
> don't have any explicit use case at the moment. Actually, I compare
> concurrency frameworks and want to figure out if this is possible with
> GPars Actors.

I think the very concept of a "transaction over several actors" is
anathema to the whole idea of actors, it doesn't matter which framework
is being used. An actor system is a system founded on asynchronous
messaging and behaviour. Transactions would require global synchronous
messaging and locking, something at the opposite end of computational
models.

Dataflow (or CSP) could in principle allow for synchronous behaviour of
multiple operators if there was a global clock since activation of an
operator is dependent on message reception.

Of course having said the above I can envisage realizing the dataflow
idea with actors, but it would nonethless rely on a global clock.

So basically no! :-)

--
Russel.
=============================================================================
Dr Russel Winder      t: <a href="tel:%2B44%2020%207585%202200" value="+442075852200" target="_blank">+44 20 7585 2200   voip: [hidden email]
41 Buckmaster Road    m: <a href="tel:%2B44%207770%20465%20077" value="+447770465077" target="_blank">+44 7770 465 077   xmpp: [hidden email]
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Reply | Threaded
Open this post in threaded view
|

Re: Actors-Transaction

Russel Winder-3
On Mon, 2013-08-12 at 22:03 +0200, Paolo Di Tommaso wrote:
> I think Thomas is comparing Gpars Actors to Akka, which supports
> transactions over the actor model.

Sounds like Akka is trying to use actors where actors are the wrong
architectural model then. I would need to see some examples, to have
anything more concrete to add.

Hopefully in his comparison, Thomas is ensuring to record whether a
feature is good or bad, not just if it is present. If a feature is a bad
feature then it is a good thing if a framework doesn't have it!

--
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:[hidden email]
41 Buckmaster Road    m: +44 7770 465 077   xmpp: [hidden email]
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Actors-Transaction

Paolo Di Tommaso
I've never used it, but I see it in the documentation. They call it Transactors 



Best,
Paolo



On Tue, Aug 13, 2013 at 1:16 PM, Russel Winder <[hidden email]> wrote:
On Mon, 2013-08-12 at 22:03 +0200, Paolo Di Tommaso wrote:
> I think Thomas is comparing Gpars Actors to Akka, which supports
> transactions over the actor model.

Sounds like Akka is trying to use actors where actors are the wrong
architectural model then. I would need to see some examples, to have
anything more concrete to add.

Hopefully in his comparison, Thomas is ensuring to record whether a
feature is good or bad, not just if it is present. If a feature is a bad
feature then it is a good thing if a framework doesn't have it!

--
Russel.
=============================================================================
Dr Russel Winder      t: <a href="tel:%2B44%2020%207585%202200" value="+442075852200">+44 20 7585 2200   voip: [hidden email]
41 Buckmaster Road    m: <a href="tel:%2B44%207770%20465%20077" value="+447770465077">+44 7770 465 077   xmpp: [hidden email]
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Reply | Threaded
Open this post in threaded view
|

Re: Actors-Transaction

Russel Winder-3
On Tue, 2013-08-13 at 13:24 +0200, Paolo Di Tommaso wrote:
> I've never used it, but I see it in the documentation. They call it
> Transactors
>
> http://doc.akka.io/docs/akka/snapshot/java/transactors.html

Hummm… I need to look at this for more than a couple of minutes but my
first reaction is one of scepticism.  Actors are fine for asynchronous
activity but not for synchronous, as the Akka page points out. STM is
all about shared state, a lower-level abstraction. Clearly STM is a good
fit for singleton caches and the like. Ramming the two together seems
like a bad move, much better to use some form of dataflow architecture

Thanks for the pointer, it is now on my reading list.

--
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:[hidden email]
41 Buckmaster Road    m: +44 7770 465 077   xmpp: [hidden email]
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc (205 bytes) Download Attachment