SlideShare una empresa de Scribd logo
1 de 93
Descargar para leer sin conexión
State You’re Doing it Wrong:
Alternative Concurrency
Paradigms For the JVM
Jonas Bonér
Crisp AB
blog: http://jonasboner.com
work: http://crisp.se
code: http://github.com/jboner
twitter: jboner
Agenda
> An Emergent Crisis
> State: Identity vs Value
> Shared-State Concurrency
> Software Transactional Memory (STM)
> Message-Passing Concurrency (Actors)
> Dataflow Concurrency
> Wrap up




                                         2
Moore’s Law
> Coined in the 1965 paper by Gordon E. Moore
> The number of transistors is doubling every
  18 months
> Processor manufacturers have solved our
  problems for years




                                                3
Not anymore

              4
The free lunch is over
> Theend of Moore’s Law
> We can’t squeeze more out of one CPU




                                         5
Conclusion
> This is an emergent crisis
> Multi-processors are here to stay
> We need to learn to take advantage of that
> The world is going concurrent




                                               6
State
        7
The devil is in
  the state



                  8
Wrong,
let me rephrase


                  9
The devil is in
the mutable state



                    10
Definitions
     &
Philosophy

              11
What is a Value?
A Value is something that
 does not change
       Discussion based on
       http://clojure.org/state
           by Rich Hickey



                                  12
What is an Identity?
  A stable logical entity
    associated with a
series of different Values
        over time


                             13
What is State?
   The Value
 an entity with a
 specific Identity
has at a particular
  point in time

                      14
How do we know if
    something has State?
  If a function is invoked with
     the same arguments at
two different points in time and
     returns different values...

      ...then it has state
                              15
The Problem
  Unification of
Identity & Value
    They are
      not
   the same
                   16
We need to separate Identity & Value
...add a level of indirection
Software Transactional Memory
  Managed References

Message-Passing Concurrency
  Actors/Active Objects

Dataflow Concurrency
  Dataflow (Single-Assignment) Variables
                                           17
Shared-State
Concurrency


               18
Shared-State Concurrency
> Concurrent access to shared, mutable state.
> Protect mutable state with locks
> The
   Java

   C#

   C/C++

   Ruby

   Python

   etc.

   ...way



                                                19
Shared-State Concurrency is
incredibly hard
> Inherentlyvery hard to use reliably
> Even the experts get it wrong




                                        20
Roadmap:
   Let’s look at three problem domains
1. Need for consensus and truly shared knowledge
  Example: Banking

2. Coordination of independent tasks/processes
  Example: Scheduling, Gaming

3. Workflow related dependent processes
  Example: Business processes, MapReduce




                                                 21
...and for each of these...
1. Look at an implementation using
   Shared-State Concurrency

2. Compare with implementation using an
   alternative paradigm




                                          22
Roadmap:
   Let’s look at three problem domains
1. Need for consensus and truly shared knowledge
  Example: Banking

2. Coordination of independent tasks/processes
  Example: Scheduling, Gaming

3. Workflow related dependent processes
  Example: Business processes, MapReduce




                                                 23
Problem 1:
    Transfer funds
between bank accounts


                        24
Shared-State Concurrency
        Transfer funds
    between bank accounts


                            25
Account
public
class
Account
{




private
double
balance;




public
void
withdraw(double
amount)
{





balance
‐=
amount;



}




public
void
deposit(double
amount)
{





balance
+=
amount;



}


}

>   Not thread-safe

                                       26
Let’s make it thread-safe
public
class
Account
{




private
double
balance;




public
synchronized
void
withdraw(double
amount)
{





balance
‐=
amount;



}




public
synchronized
void
deposit(double
amount)
{





balance
+=
amount;



}


}

>Thread-safe,      right? 


                                                 27
It’s still broken
     Not atomic



                  28
Let’s write an atomic transfer method
 public
class
Account
{
 

...



public
synchronized
void
transferTo(





Account
to,
double
amount)
{





this.withdraw(amount);







to.deposit(amount);



}





...

}

>   This will work right?
                                          29
Let’s transfer funds
Account
alice
=
...


Account
bob
=
...





//
in
one
thread


alice.transferTo(bob,
10.0D);





//
in
another
thread


bob.transferTo(alice,
3.0D);




                                  30
Might lead to
DEADLOCK
Darn, this is really hard!!!


                               31
We need to enforce lock ordering
> How?
> Java won’t help us
> Need to use code convention (names etc.)
> Requires knowledge about the internal state
  and implementation of Account
> …runs counter to the principles of
  encapsulation in OOP
> Opens up a Can of Worms




                                                32
The problem with locks
Locks do not compose
Taking too few locks
Taking too many locks
Taking the wrong locks
Taking locks in the wrong order
Error recovery is hard




                                  33
Java bet on the
  wrong horse
But we’re not completely screwed
     There are alternatives


                                   34
We need better
and more high-level
   abstractions


                      35
Alternative Paradigms
>Software Transactional Memory (STM)
>Message-Passing Concurrency (Actors)
>Dataflow Concurrency




                                 36
Software Transactional
    Memory (STM)


                     37
Software Transactional Memory
> See   the memory (heap and stack) as a
  transactional dataset
> Similar to a database
   begin

   commit

   abort/rollback

> Transactions are retried automatically upon
  collision
> Rolls back the memory on abort




                                                38
Software Transactional Memory
> Transactions can nest
> Transactions compose (yipee!!)



atomic
{








..








atomic
{











..









}





}






                                   39
Restrictions
> All
    operations in scope of a transaction:
  Need to be idempotent

  Can’t have side-effects




                                            40
Case study:
Clojure

              41
What is Clojure?
> Functionallanguage
> Runs on the JVM
> Only immutable data and datastructures
> Pragmatic Lisp
> Great Java interoperability
> Dynamic, but very fast




                                           42
Clojure’s concurrency story
> STM  (Refs)
   Synchronous Coordinated

> Atoms
   Synchronous Uncoordinated

> Agents
   Asynchronous Uncoordinated

> Vars
   Synchronous Thread Isolated




                                  43
STM (Refs)
>A  Ref holds a reference to an immutable value
> A Ref can only be changed in a transaction
> Updates are atomic and isolated (ACI)
> A transaction sees its own snapshot of the world
> Transactions are retried upon collision




                                                 44
Let’s get back to our banking problem




    The STM way
      Transfer funds
  between bank accounts

                                        45
Create two accounts
;;
alice’s
account
with
balance
1000
USD
(def
alice
(ref
1000))


;;
bob’s
account
with
balance
1000
USD
(def
bob
(ref
1000))





                                         46
Transfer 100 bucks
;;
amount
to
transfer
(def
amount
100)







;;
not
valid
;;
throws
exception
since

;;
no
transaction
is
running
(ref‐set
alice
(‐
@alice
amount))

(ref‐set
bob
(+
@bob
amount))




                                     47
Wrap in a transaction

;;
update
both
accounts
inside
a
transaction
(dosync



(ref‐set
alice
(‐
@alice
amount))


(ref‐set
bob
(+
@bob
amount)))




                                       48
Potential problems with STM
High contention (many transaction collisions) can lead to:
   Potential bad performance and too high latency
   Progress can not be guaranteed (e.g. live locking)
   Fairness is not maintained
Implementation details hidden in black box




                                                   49
My (humble) opinion on STM
> Can  never work fine in a language that don’t have
 compiler enforced immutability
 > E.g. never in Java (as of today)


> Shouldnot be used to “patch” Shared-State
 Concurrency

> Still
     a research topic how to do it in imperative
 languages


                                                   50
Discussion: Problem 1
Need for consensus and truly shared knowledge
Shared-State Concurrency
  Bad fit
Software Transactional Memory
   Great fit
Message-Passing Concurrency
  Terrible fit
Dataflow Concurrency
  Terrible fit


                                                51
Message-Passing
  Concurrency


                  52
Actor Model of Concurrency
> Implements   Message-Passing Concurrency
> Originates in a 1973 paper by Carl Hewitt
> Implemented in Erlang, Occam, Oz
> Encapsulates state and behavior
> Closer to the definition of OO than classes




                                                53
Actor Model of Concurrency
> Share  NOTHING
> Isolated lightweight processes
 >   Can easily create millions on a single workstation
> Communicates  through messages
> Asynchronous and non-blocking




                                                          54
Actor Model of Concurrency
> No shared state
   … hence, nothing to synchronize.

> Each actor has a mailbox (message queue)




                                             55
Actor Model of Concurrency
> Non-blocking    send
> Blocking receive
> Messages are immutable
> Highly performant and scalable
   Similar to Staged Event Driven Achitecture style (SEDA)




                                                   56
Actor Model of Concurrency
> Easier   to reason about
> Raised abstraction level
> Easier to avoid
   Race conditions

   Deadlocks

   Starvation

   Live locks




                             57
Fault-tolerant systems
> Link   actors
> Supervisor hierarchies
   One-for-one

   All-for-one

> Ericsson’s Erlang success story
   9 nines availability (31 ms/year downtime)




                                                 58
Roadmap:
   Let’s look at three problem domains
1. Need for consensus and truly shared knowledge
  Example: Banking

2. Coordination of independent tasks/processes
  Example: Scheduling, Gaming

3. Workflow related dependent processes
  Example: Business processes, MapReduce




                                                 59
Problem 2:
A game of ping pong



                      60
Shared-State Concurrency
     A game of ping pong



                           61
Ping Pong Table
public
class
PingPongTable
{


public
void
hit(String
hitter)
{




System.out.println(hitter);


}
}




                                     62
Player
 public
class
Player
implements
Runnable
{
 

private
PingPongTable
myTable;

 

private
String
myName;
 

public
Player(String
name,

 















PingPongTable
table)
{
 



myName
=
name;
 



myTable
=
table;
 

}

 

...
 }
                                      63
Player cont...


...


public
void
run()
{




while
(true)
{






synchronized(myTable)
{








try
{










myTable.hit(myName);










myTable.notifyAll();










myTable.wait();








}
catch
(InterruptedException
e)
{}






}




}


}
}
                                              64
Run it
PingPongTable
table
=
new
PingPongTable();
Thread
ping
=





new
Thread(new
Player("Ping",
table));
Thread
pong
=





new
Thread(new
Player("Pong",
table));
ping.start();

pong.start();





                                       65
Help: java.util.concurrent
> Great  library
> Raises the abstraction level
  > No more wait/notify & synchronized blocks
  > Concurrent collections
  > Executors, ParallelArray
> Simplifies concurrent code
> Use it, don’t roll your own




                                                66
Actors
A game of ping pong



                      67
Define message




    case
object
Ball



                       68
Player 1: Pong

val
pong
=
actor
{




loop
{







receive
{





//
wait
on
message








case
Ball
=>
//
match
on
message
Ball










println("Pong")










reply(Ball)






}




}


}

                                       69
Player 2: Ping

val
ping
=
actor
{




pong
!
Ball
//
start
the
game




loop
{







receive
{








case
Ball
=>











println("Ping")










reply(Ball)






}




}


}
                                    70
Run it
...well, they are already up and running




                                           71
Actor implementations for the JVM
> Killim(Java)
> Jetlang (Java)
> Actor’s Guild (Java)
> ActorFoundry (Java)
> Actorom (Java)
> FunctionalJava (Java)
> Akka Actor Kernel (Java/Scala)
> GParallelizer (Groovy)
> Fan Actors (Fan)



                                    72
Discussion: Problem 2
Coordination of interrelated tasks/processes

Shared-State Concurrency
  Bad fit (ok if java.util.concurrent is used)
STM
  Won’t help
Message-Passing Concurrency
  Great fit
Dataflow Concurrency
  Ok


                                                 73
Dataflow Concurrency
  The forgotten paradigm




                           74
Dataflow Concurrency
> Declarative
> No  observable non-determinism
> Data-driven – threads block until data is available
> On-demand, lazy
> No difference between:
  > Concurrent and
  > Sequential code




                                                   75
Dataflow Concurrency
> No race-conditions
> Deterministic
> Simple and beautiful




                         76
Dataflow Concurrency
> Dataflow (Single-Assignment) Variables
> Dataflow Streams (the tail is a dataflow variable)
> Implemented in Oz and Alice




                                                   77
Just three operations
> Create  a dataflow variable
> Wait for the variable to be bound
> Bind the variable




                                      78
Limitations
> Can’t  have side-effects
   Exceptions

   IO (println, File, Socket etc.)

   Time

   etc.

 Not general-purpose

 Generally good for well-defined isolated modules




                                                79
Oz-style dataflow concurrency for the JVM
> Created   my own implementation (DSL)
 >   On top of Scala




                                          80
API: Dataflow Variable
//
Create
dataflow
variable


val
x,
y,
z
=
new
DataFlowVariable[Int]





//
Access
dataflow
variable
(Wait
to
be
bound)


z()





//
Bind
dataflow
variable


x
<<
40





//
Lightweight
thread


thread
{
y
<<
2
}


                                            81
API: Dataflow Stream
Deterministic streams (not IO streams)

//
Create
dataflow
stream


val
producer
=
new
DataFlowStream[Int]





//
Append
to
stream


producer
<<<
s





//
Read
from
stream


producer()




                                         82
Roadmap:
   Let’s look at three problem domains
1. Need for consensus and truly shared knowledge
  Example: Banking

2. Coordination of independent tasks/processes
  Example: Scheduling, Gaming

3. Workflow related dependent processes
  Example: Business processes, MapReduce




                                                 83
Problem 3:
Producer/Consumer



                    84
Shared-State Concurrency
     Producer/Consumer



                         85
Use java.util.concurrent
Fork/Join framework (ParallelArray etc.)
ExecutorService
Future
BlockingQueue




                                           86
Dataflow Concurrency
   Producer/Consumer



                       87
Example: Dataflow Variables
//
sequential
version
val
x,
y,
z
=
new
DataFlowVariable[Int]


x
<<
40

y
<<
2
z
<<
x()
+
y()


println("z
=
"
+
z())






                                       88
Example: Dataflow Variables
//
concurrent
version:
no
difference
val
x,
y,
z
=
new
DataFlowVariable[Int]


thread
{
x
<<
40
}


thread
{
y
<<
2
}


thread
{




z
<<
x()
+
y()




println("z
=
"
+
z())


}



                                       89
Dataflow Concurrency in Java

DataRush (commercial)
Flow-based Programming in Java (dead?)
FlowJava (academic and dead)




                                         90
Discussion: Problem 3
Workflow related dependent processes

Shared-State Concurrency
  Ok (if java.util.concurrent is used)
STM
  Won’t help
Message-Passing Concurrency
  Ok
Dataflow Concurrency
  Great fit


                                         91
Wrap up
> Parallel programs is becoming increasingly important
> We need a simpler way of writing concurrent
  programs
> “Java-style” concurrency is too hard
> There are alternatives worth exploring
   Message-Passing Concurrency

   Software Transactional Memory

   Dataflow Concurrency

 Each with their strengths and weaknesses




                                                92
Jonas Bonér
Crisp AB
blog: http://jonasboner.com
work: http://crisp.se
code: http://github.com/jboner
twitter: jboner

                           93

Más contenido relacionado

Destacado

SACSIS2009_TCP.pdf
SACSIS2009_TCP.pdfSACSIS2009_TCP.pdf
SACSIS2009_TCP.pdfHiroshi Ono
 
pragmaticrealworldscalajfokus2009-1233251076441384-2.pdf
pragmaticrealworldscalajfokus2009-1233251076441384-2.pdfpragmaticrealworldscalajfokus2009-1233251076441384-2.pdf
pragmaticrealworldscalajfokus2009-1233251076441384-2.pdfHiroshi Ono
 
BOF1-Scala02.pdf
BOF1-Scala02.pdfBOF1-Scala02.pdf
BOF1-Scala02.pdfHiroshi Ono
 
Characterizing the Splogosphere
Characterizing the SplogosphereCharacterizing the Splogosphere
Characterizing the SplogosphereHiroshi Ono
 
A Scalable, Commodity Data Center Network Architecture
A Scalable, Commodity Data Center Network ArchitectureA Scalable, Commodity Data Center Network Architecture
A Scalable, Commodity Data Center Network ArchitectureHiroshi Ono
 
Elasticfox Owners Manual
Elasticfox Owners ManualElasticfox Owners Manual
Elasticfox Owners ManualHiroshi Ono
 
The Evolution of Internet-Scale Event Notification Services
The Evolution of Internet-Scale Event Notification ServicesThe Evolution of Internet-Scale Event Notification Services
The Evolution of Internet-Scale Event Notification ServicesHiroshi Ono
 
Tarea 4
Tarea 4Tarea 4
Tarea 4JKGM
 
Normas iso 27001 27002 paola enríquez 9 c1
Normas iso 27001  27002 paola enríquez 9 c1Normas iso 27001  27002 paola enríquez 9 c1
Normas iso 27001 27002 paola enríquez 9 c1paokatherine
 
Book de fotos pinheirinho
Book de fotos pinheirinhoBook de fotos pinheirinho
Book de fotos pinheirinhoPaulo Barros
 
G324 use, develop or challenege 2011
G324 use, develop or challenege 2011G324 use, develop or challenege 2011
G324 use, develop or challenege 2011kmuzira
 
Pa yessy
Pa yessyPa yessy
Pa yessySJM
 
7. segunda guerra mundial
7. segunda guerra mundial7. segunda guerra mundial
7. segunda guerra mundial418pumas
 

Destacado (20)

SACSIS2009_TCP.pdf
SACSIS2009_TCP.pdfSACSIS2009_TCP.pdf
SACSIS2009_TCP.pdf
 
pragmaticrealworldscalajfokus2009-1233251076441384-2.pdf
pragmaticrealworldscalajfokus2009-1233251076441384-2.pdfpragmaticrealworldscalajfokus2009-1233251076441384-2.pdf
pragmaticrealworldscalajfokus2009-1233251076441384-2.pdf
 
BOF1-Scala02.pdf
BOF1-Scala02.pdfBOF1-Scala02.pdf
BOF1-Scala02.pdf
 
Characterizing the Splogosphere
Characterizing the SplogosphereCharacterizing the Splogosphere
Characterizing the Splogosphere
 
A Scalable, Commodity Data Center Network Architecture
A Scalable, Commodity Data Center Network ArchitectureA Scalable, Commodity Data Center Network Architecture
A Scalable, Commodity Data Center Network Architecture
 
Elasticfox Owners Manual
Elasticfox Owners ManualElasticfox Owners Manual
Elasticfox Owners Manual
 
The Evolution of Internet-Scale Event Notification Services
The Evolution of Internet-Scale Event Notification ServicesThe Evolution of Internet-Scale Event Notification Services
The Evolution of Internet-Scale Event Notification Services
 
Presentacion de power point copia
Presentacion de power point   copiaPresentacion de power point   copia
Presentacion de power point copia
 
Tarea 4
Tarea 4Tarea 4
Tarea 4
 
Normas iso 27001 27002 paola enríquez 9 c1
Normas iso 27001  27002 paola enríquez 9 c1Normas iso 27001  27002 paola enríquez 9 c1
Normas iso 27001 27002 paola enríquez 9 c1
 
Book de fotos pinheirinho
Book de fotos pinheirinhoBook de fotos pinheirinho
Book de fotos pinheirinho
 
Be Happy Freguesia
Be Happy FreguesiaBe Happy Freguesia
Be Happy Freguesia
 
G324 use, develop or challenege 2011
G324 use, develop or challenege 2011G324 use, develop or challenege 2011
G324 use, develop or challenege 2011
 
Postales de navidad juviles
Postales de navidad juvilesPostales de navidad juviles
Postales de navidad juviles
 
Apresentação
ApresentaçãoApresentação
Apresentação
 
Presentation1
Presentation1Presentation1
Presentation1
 
Pa yessy
Pa yessyPa yessy
Pa yessy
 
abc
abcabc
abc
 
O que é Software Livre
O que é Software LivreO que é Software Livre
O que é Software Livre
 
7. segunda guerra mundial
7. segunda guerra mundial7. segunda guerra mundial
7. segunda guerra mundial
 

Similar a stateyouredoingitwrongjavaone2009-090617031310-phpapp02.pdf

DIY: A distributed database cluster, or: MySQL Cluster
DIY: A distributed database cluster, or: MySQL ClusterDIY: A distributed database cluster, or: MySQL Cluster
DIY: A distributed database cluster, or: MySQL ClusterUlf Wendel
 
The free lunch is over
The free lunch is overThe free lunch is over
The free lunch is overThadeu Russo
 
Cache Consistency – Requirements and its packet processing Performance implic...
Cache Consistency – Requirements and its packet processing Performance implic...Cache Consistency – Requirements and its packet processing Performance implic...
Cache Consistency – Requirements and its packet processing Performance implic...Michelle Holley
 
BlockChain for the Banker
BlockChain for the BankerBlockChain for the Banker
BlockChain for the BankerBohdan Szymanik
 
Exploiting Concurrency with Dynamic Languages
Exploiting Concurrency with Dynamic LanguagesExploiting Concurrency with Dynamic Languages
Exploiting Concurrency with Dynamic LanguagesTobias Lindaaker
 
Sharding in MongoDB 4.2 #what_is_new
 Sharding in MongoDB 4.2 #what_is_new Sharding in MongoDB 4.2 #what_is_new
Sharding in MongoDB 4.2 #what_is_newAntonios Giannopoulos
 
Reactsf 2014-message-driven
Reactsf 2014-message-drivenReactsf 2014-message-driven
Reactsf 2014-message-drivenTodd Montgomery
 
Session 9 Tp9
Session 9 Tp9Session 9 Tp9
Session 9 Tp9phanleson
 
Operating System Process Synchronization
Operating System Process SynchronizationOperating System Process Synchronization
Operating System Process SynchronizationHaziq Naeem
 
Reactive Design Patterns: a talk by Typesafe's Dr. Roland Kuhn
Reactive Design Patterns: a talk by Typesafe's Dr. Roland KuhnReactive Design Patterns: a talk by Typesafe's Dr. Roland Kuhn
Reactive Design Patterns: a talk by Typesafe's Dr. Roland KuhnZalando Technology
 
Managing Unstructured Data: Lobs in the World of JSON
Managing Unstructured Data: Lobs in the World of JSONManaging Unstructured Data: Lobs in the World of JSON
Managing Unstructured Data: Lobs in the World of JSONMichael Rosenblum
 
Microservices for performance - GOTO Chicago 2016
Microservices for performance - GOTO Chicago 2016Microservices for performance - GOTO Chicago 2016
Microservices for performance - GOTO Chicago 2016Peter Lawrey
 
Alternate concurrency models
Alternate concurrency modelsAlternate concurrency models
Alternate concurrency modelsAbid Khan
 
Chronicle accelerate building a digital currency
Chronicle accelerate   building a digital currencyChronicle accelerate   building a digital currency
Chronicle accelerate building a digital currencyPeter Lawrey
 

Similar a stateyouredoingitwrongjavaone2009-090617031310-phpapp02.pdf (20)

DIY: A distributed database cluster, or: MySQL Cluster
DIY: A distributed database cluster, or: MySQL ClusterDIY: A distributed database cluster, or: MySQL Cluster
DIY: A distributed database cluster, or: MySQL Cluster
 
Ho20
Ho20Ho20
Ho20
 
The free lunch is over
The free lunch is overThe free lunch is over
The free lunch is over
 
Cache Consistency – Requirements and its packet processing Performance implic...
Cache Consistency – Requirements and its packet processing Performance implic...Cache Consistency – Requirements and its packet processing Performance implic...
Cache Consistency – Requirements and its packet processing Performance implic...
 
A
AA
A
 
BlockChain for the Banker
BlockChain for the BankerBlockChain for the Banker
BlockChain for the Banker
 
Exploiting Concurrency with Dynamic Languages
Exploiting Concurrency with Dynamic LanguagesExploiting Concurrency with Dynamic Languages
Exploiting Concurrency with Dynamic Languages
 
Sharding in MongoDB 4.2 #what_is_new
 Sharding in MongoDB 4.2 #what_is_new Sharding in MongoDB 4.2 #what_is_new
Sharding in MongoDB 4.2 #what_is_new
 
Actor Model
Actor ModelActor Model
Actor Model
 
Reactsf 2014-message-driven
Reactsf 2014-message-drivenReactsf 2014-message-driven
Reactsf 2014-message-driven
 
Session 9 Tp9
Session 9 Tp9Session 9 Tp9
Session 9 Tp9
 
Operating System Process Synchronization
Operating System Process SynchronizationOperating System Process Synchronization
Operating System Process Synchronization
 
Reactive Design Patterns: a talk by Typesafe's Dr. Roland Kuhn
Reactive Design Patterns: a talk by Typesafe's Dr. Roland KuhnReactive Design Patterns: a talk by Typesafe's Dr. Roland Kuhn
Reactive Design Patterns: a talk by Typesafe's Dr. Roland Kuhn
 
Managing Unstructured Data: Lobs in the World of JSON
Managing Unstructured Data: Lobs in the World of JSONManaging Unstructured Data: Lobs in the World of JSON
Managing Unstructured Data: Lobs in the World of JSON
 
Microservices for performance - GOTO Chicago 2016
Microservices for performance - GOTO Chicago 2016Microservices for performance - GOTO Chicago 2016
Microservices for performance - GOTO Chicago 2016
 
ClickHouse Keeper
ClickHouse KeeperClickHouse Keeper
ClickHouse Keeper
 
Ch3-2
Ch3-2Ch3-2
Ch3-2
 
Alternate concurrency models
Alternate concurrency modelsAlternate concurrency models
Alternate concurrency models
 
01 what is blockchain
01 what is blockchain01 what is blockchain
01 what is blockchain
 
Chronicle accelerate building a digital currency
Chronicle accelerate   building a digital currencyChronicle accelerate   building a digital currency
Chronicle accelerate building a digital currency
 

Más de Hiroshi Ono

Voltdb - wikipedia
Voltdb - wikipediaVoltdb - wikipedia
Voltdb - wikipediaHiroshi Ono
 
Gamecenter概説
Gamecenter概説Gamecenter概説
Gamecenter概説Hiroshi Ono
 
EventDrivenArchitecture
EventDrivenArchitectureEventDrivenArchitecture
EventDrivenArchitectureHiroshi Ono
 
program_draft3.pdf
program_draft3.pdfprogram_draft3.pdf
program_draft3.pdfHiroshi Ono
 
nodalities_issue7.pdf
nodalities_issue7.pdfnodalities_issue7.pdf
nodalities_issue7.pdfHiroshi Ono
 
genpaxospublic-090703114743-phpapp01.pdf
genpaxospublic-090703114743-phpapp01.pdfgenpaxospublic-090703114743-phpapp01.pdf
genpaxospublic-090703114743-phpapp01.pdfHiroshi Ono
 
kademlia-1227143905867010-8.pdf
kademlia-1227143905867010-8.pdfkademlia-1227143905867010-8.pdf
kademlia-1227143905867010-8.pdfHiroshi Ono
 
downey08semaphores.pdf
downey08semaphores.pdfdowney08semaphores.pdf
downey08semaphores.pdfHiroshi Ono
 
TwitterOct2008.pdf
TwitterOct2008.pdfTwitterOct2008.pdf
TwitterOct2008.pdfHiroshi Ono
 
stateyouredoingitwrongjavaone2009-090617031310-phpapp02.pdf
stateyouredoingitwrongjavaone2009-090617031310-phpapp02.pdfstateyouredoingitwrongjavaone2009-090617031310-phpapp02.pdf
stateyouredoingitwrongjavaone2009-090617031310-phpapp02.pdfHiroshi Ono
 
SACSIS2009_TCP.pdf
SACSIS2009_TCP.pdfSACSIS2009_TCP.pdf
SACSIS2009_TCP.pdfHiroshi Ono
 
scalaliftoff2009.pdf
scalaliftoff2009.pdfscalaliftoff2009.pdf
scalaliftoff2009.pdfHiroshi Ono
 
stateyouredoingitwrongjavaone2009-090617031310-phpapp02.pdf
stateyouredoingitwrongjavaone2009-090617031310-phpapp02.pdfstateyouredoingitwrongjavaone2009-090617031310-phpapp02.pdf
stateyouredoingitwrongjavaone2009-090617031310-phpapp02.pdfHiroshi Ono
 
program_draft3.pdf
program_draft3.pdfprogram_draft3.pdf
program_draft3.pdfHiroshi Ono
 
nodalities_issue7.pdf
nodalities_issue7.pdfnodalities_issue7.pdf
nodalities_issue7.pdfHiroshi Ono
 
kademlia-1227143905867010-8.pdf
kademlia-1227143905867010-8.pdfkademlia-1227143905867010-8.pdf
kademlia-1227143905867010-8.pdfHiroshi Ono
 
pragmaticrealworldscalajfokus2009-1233251076441384-2.pdf
pragmaticrealworldscalajfokus2009-1233251076441384-2.pdfpragmaticrealworldscalajfokus2009-1233251076441384-2.pdf
pragmaticrealworldscalajfokus2009-1233251076441384-2.pdfHiroshi Ono
 
downey08semaphores.pdf
downey08semaphores.pdfdowney08semaphores.pdf
downey08semaphores.pdfHiroshi Ono
 
TwitterOct2008.pdf
TwitterOct2008.pdfTwitterOct2008.pdf
TwitterOct2008.pdfHiroshi Ono
 

Más de Hiroshi Ono (20)

Voltdb - wikipedia
Voltdb - wikipediaVoltdb - wikipedia
Voltdb - wikipedia
 
Gamecenter概説
Gamecenter概説Gamecenter概説
Gamecenter概説
 
EventDrivenArchitecture
EventDrivenArchitectureEventDrivenArchitecture
EventDrivenArchitecture
 
program_draft3.pdf
program_draft3.pdfprogram_draft3.pdf
program_draft3.pdf
 
nodalities_issue7.pdf
nodalities_issue7.pdfnodalities_issue7.pdf
nodalities_issue7.pdf
 
genpaxospublic-090703114743-phpapp01.pdf
genpaxospublic-090703114743-phpapp01.pdfgenpaxospublic-090703114743-phpapp01.pdf
genpaxospublic-090703114743-phpapp01.pdf
 
kademlia-1227143905867010-8.pdf
kademlia-1227143905867010-8.pdfkademlia-1227143905867010-8.pdf
kademlia-1227143905867010-8.pdf
 
downey08semaphores.pdf
downey08semaphores.pdfdowney08semaphores.pdf
downey08semaphores.pdf
 
TwitterOct2008.pdf
TwitterOct2008.pdfTwitterOct2008.pdf
TwitterOct2008.pdf
 
camel-scala.pdf
camel-scala.pdfcamel-scala.pdf
camel-scala.pdf
 
stateyouredoingitwrongjavaone2009-090617031310-phpapp02.pdf
stateyouredoingitwrongjavaone2009-090617031310-phpapp02.pdfstateyouredoingitwrongjavaone2009-090617031310-phpapp02.pdf
stateyouredoingitwrongjavaone2009-090617031310-phpapp02.pdf
 
SACSIS2009_TCP.pdf
SACSIS2009_TCP.pdfSACSIS2009_TCP.pdf
SACSIS2009_TCP.pdf
 
scalaliftoff2009.pdf
scalaliftoff2009.pdfscalaliftoff2009.pdf
scalaliftoff2009.pdf
 
stateyouredoingitwrongjavaone2009-090617031310-phpapp02.pdf
stateyouredoingitwrongjavaone2009-090617031310-phpapp02.pdfstateyouredoingitwrongjavaone2009-090617031310-phpapp02.pdf
stateyouredoingitwrongjavaone2009-090617031310-phpapp02.pdf
 
program_draft3.pdf
program_draft3.pdfprogram_draft3.pdf
program_draft3.pdf
 
nodalities_issue7.pdf
nodalities_issue7.pdfnodalities_issue7.pdf
nodalities_issue7.pdf
 
kademlia-1227143905867010-8.pdf
kademlia-1227143905867010-8.pdfkademlia-1227143905867010-8.pdf
kademlia-1227143905867010-8.pdf
 
pragmaticrealworldscalajfokus2009-1233251076441384-2.pdf
pragmaticrealworldscalajfokus2009-1233251076441384-2.pdfpragmaticrealworldscalajfokus2009-1233251076441384-2.pdf
pragmaticrealworldscalajfokus2009-1233251076441384-2.pdf
 
downey08semaphores.pdf
downey08semaphores.pdfdowney08semaphores.pdf
downey08semaphores.pdf
 
TwitterOct2008.pdf
TwitterOct2008.pdfTwitterOct2008.pdf
TwitterOct2008.pdf
 

stateyouredoingitwrongjavaone2009-090617031310-phpapp02.pdf