Maglev Rubyfuza, Cape Town, 2012

559 views
500 views

Published on

Rudi Engelbrecht explores Maglev in a hands on tutorial. Topics such as transparent object persistence, concurrency, multiple Ruby VM's accessing the same objects, persisting Ruby procs and Continuations are illustrated. Source code is on https://github.com/rle

Published in: Travel, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
559
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
12
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • \n
  • gcgem\n
  • gcgem\n
  • gcgem\n
  • gcgem\n
  • gcgem\n
  • gcgem\n
  • gcgem\n
  • gcgem\n
  • gcgem\n
  • gcgem\n
  • gcgem\n
  • gcgem\n
  • gcgem\n
  • gcgem\n
  • gcgem\n
  • gcgem\n
  • gcgem\n
  • gcgem\n
  • gcgem\n
  • gcgem\n
  • Consistency levels\nDegree 0 - None\nDegree 1 - Locking READ UNCOMMITTED\nDegree 2 - Locking READ COMMITTED\nLocking REPEATABLE READ\nDegree 3 - Locking SERIALIZABLE\n
  • Consistency levels\nDegree 0 - None\nDegree 1 - Locking READ UNCOMMITTED\nDegree 2 - Locking READ COMMITTED\nLocking REPEATABLE READ\nDegree 3 - Locking SERIALIZABLE\n
  • Consistency levels\nDegree 0 - None\nDegree 1 - Locking READ UNCOMMITTED\nDegree 2 - Locking READ COMMITTED\nLocking REPEATABLE READ\nDegree 3 - Locking SERIALIZABLE\n
  • Consistency levels\nDegree 0 - None\nDegree 1 - Locking READ UNCOMMITTED\nDegree 2 - Locking READ COMMITTED\nLocking REPEATABLE READ\nDegree 3 - Locking SERIALIZABLE\n
  • Consistency levels\nDegree 0 - None\nDegree 1 - Locking READ UNCOMMITTED\nDegree 2 - Locking READ COMMITTED\nLocking REPEATABLE READ\nDegree 3 - Locking SERIALIZABLE\n
  • Logical Architecture\n
  • Demonstration architecture\nRoot object - carrot orange\n
  • show hat, rabbit and cat\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • owynn = Person.new("Owynn")\nunclebob = persons[0].followers[1]\nunclebob.add_follower(owynn)\n
  • note the persistence by reachability\ncould also just add dhh\nshow persons[0].followers[0].followers[0].followers[1] is the reference to noob2\nalso persons[0].followers[1].followers[1] is reference to noob2\n
  • note the persistence by reachability\ncould also just add dhh\nshow persons[0].followers[0].followers[0].followers[1] is the reference to noob2\nalso persons[0].followers[1].followers[1] is reference to noob2\n
  • note the persistence by reachability\ncould also just add dhh\nshow persons[0].followers[0].followers[0].followers[1] is the reference to noob2\nalso persons[0].followers[1].followers[1] is reference to noob2\n
  • note the persistence by reachability\ncould also just add dhh\nshow persons[0].followers[0].followers[0].followers[1] is the reference to noob2\nalso persons[0].followers[1].followers[1] is reference to noob2\n
  • note the persistence by reachability\ncould also just add dhh\nshow persons[0].followers[0].followers[0].followers[1] is the reference to noob2\nalso persons[0].followers[1].followers[1] is reference to noob2\n
  • note the persistence by reachability\ncould also just add dhh\nshow persons[0].followers[0].followers[0].followers[1] is the reference to noob2\nalso persons[0].followers[1].followers[1] is reference to noob2\n
  • note the persistence by reachability\ncould also just add dhh\nshow persons[0].followers[0].followers[0].followers[1] is the reference to noob2\nalso persons[0].followers[1].followers[1] is reference to noob2\n
  • note the persistence by reachability\ncould also just add dhh\nshow persons[0].followers[0].followers[0].followers[1] is the reference to noob2\nalso persons[0].followers[1].followers[1] is reference to noob2\n
  • note the persistence by reachability\ncould also just add dhh\nshow persons[0].followers[0].followers[0].followers[1] is the reference to noob2\nalso persons[0].followers[1].followers[1] is reference to noob2\n
  • note the persistence by reachability\ncould also just add dhh\nshow persons[0].followers[0].followers[0].followers[1] is the reference to noob2\nalso persons[0].followers[1].followers[1] is reference to noob2\n
  • note the persistence by reachability\ncould also just add dhh\nshow persons[0].followers[0].followers[0].followers[1] is the reference to noob2\nalso persons[0].followers[1].followers[1] is reference to noob2\n
  • note the persistence by reachability\ncould also just add dhh\nshow persons[0].followers[0].followers[0].followers[1] is the reference to noob2\nalso persons[0].followers[1].followers[1] is reference to noob2\n
  • note the persistence by reachability\ncould also just add dhh\nshow persons[0].followers[0].followers[0].followers[1] is the reference to noob2\nalso persons[0].followers[1].followers[1] is reference to noob2\n
  • note the persistence by reachability\ncould also just add dhh\nshow persons[0].followers[0].followers[0].followers[1] is the reference to noob2\nalso persons[0].followers[1].followers[1] is reference to noob2\n
  • note the persistence by reachability\ncould also just add dhh\nshow persons[0].followers[0].followers[0].followers[1] is the reference to noob2\nalso persons[0].followers[1].followers[1] is reference to noob2\n
  • note the persistence by reachability\ncould also just add dhh\nshow persons[0].followers[0].followers[0].followers[1] is the reference to noob2\nalso persons[0].followers[1].followers[1] is reference to noob2\n
  • note the persistence by reachability\ncould also just add dhh\nshow persons[0].followers[0].followers[0].followers[1] is the reference to noob2\nalso persons[0].followers[1].followers[1] is reference to noob2\n
  • note the persistence by reachability\ncould also just add dhh\nshow persons[0].followers[0].followers[0].followers[1] is the reference to noob2\nalso persons[0].followers[1].followers[1] is reference to noob2\n
  • note the persistence by reachability\ncould also just add dhh\nshow persons[0].followers[0].followers[0].followers[1] is the reference to noob2\nalso persons[0].followers[1].followers[1] is reference to noob2\n
  • note the persistence by reachability\ncould also just add dhh\nshow persons[0].followers[0].followers[0].followers[1] is the reference to noob2\nalso persons[0].followers[1].followers[1] is reference to noob2\n
  • note the persistence by reachability\ncould also just add dhh\nshow persons[0].followers[0].followers[0].followers[1] is the reference to noob2\nalso persons[0].followers[1].followers[1] is reference to noob2\n
  • note the persistence by reachability\ncould also just add dhh\nshow persons[0].followers[0].followers[0].followers[1] is the reference to noob2\nalso persons[0].followers[1].followers[1] is reference to noob2\n
  • note the persistence by reachability\ncould also just add dhh\nshow persons[0].followers[0].followers[0].followers[1] is the reference to noob2\nalso persons[0].followers[1].followers[1] is reference to noob2\n
  • note the persistence by reachability\ncould also just add dhh\nshow persons[0].followers[0].followers[0].followers[1] is the reference to noob2\nalso persons[0].followers[1].followers[1] is reference to noob2\n
  • note the persistence by reachability\ncould also just add dhh\nshow persons[0].followers[0].followers[0].followers[1] is the reference to noob2\nalso persons[0].followers[1].followers[1] is reference to noob2\n
  • note the persistence by reachability\ncould also just add dhh\nshow persons[0].followers[0].followers[0].followers[1] is the reference to noob2\nalso persons[0].followers[1].followers[1] is reference to noob2\n
  • note the persistence by reachability\ncould also just add dhh\nshow persons[0].followers[0].followers[0].followers[1] is the reference to noob2\nalso persons[0].followers[1].followers[1] is reference to noob2\n
  • note the persistence by reachability\ncould also just add dhh\nshow persons[0].followers[0].followers[0].followers[1] is the reference to noob2\nalso persons[0].followers[1].followers[1] is reference to noob2\n
  • note the persistence by reachability\ncould also just add dhh\nshow persons[0].followers[0].followers[0].followers[1] is the reference to noob2\nalso persons[0].followers[1].followers[1] is reference to noob2\n
  • note the persistence by reachability\ncould also just add dhh\nshow persons[0].followers[0].followers[0].followers[1] is the reference to noob2\nalso persons[0].followers[1].followers[1] is reference to noob2\n
  • note the persistence by reachability\ncould also just add dhh\nshow persons[0].followers[0].followers[0].followers[1] is the reference to noob2\nalso persons[0].followers[1].followers[1] is reference to noob2\n
  • note the persistence by reachability\ncould also just add dhh\nshow persons[0].followers[0].followers[0].followers[1] is the reference to noob2\nalso persons[0].followers[1].followers[1] is reference to noob2\n
  • note the persistence by reachability\ncould also just add dhh\nshow persons[0].followers[0].followers[0].followers[1] is the reference to noob2\nalso persons[0].followers[1].followers[1] is reference to noob2\n
  • note the persistence by reachability\ncould also just add dhh\nshow persons[0].followers[0].followers[0].followers[1] is the reference to noob2\nalso persons[0].followers[1].followers[1] is reference to noob2\n
  • note the persistence by reachability\ncould also just add dhh\nshow persons[0].followers[0].followers[0].followers[1] is the reference to noob2\nalso persons[0].followers[1].followers[1] is reference to noob2\n
  • note the persistence by reachability\ncould also just add dhh\nshow persons[0].followers[0].followers[0].followers[1] is the reference to noob2\nalso persons[0].followers[1].followers[1] is reference to noob2\n
  • note the persistence by reachability\ncould also just add dhh\nshow persons[0].followers[0].followers[0].followers[1] is the reference to noob2\nalso persons[0].followers[1].followers[1] is reference to noob2\n
  • note the persistence by reachability\ncould also just add dhh\nshow persons[0].followers[0].followers[0].followers[1] is the reference to noob2\nalso persons[0].followers[1].followers[1] is reference to noob2\n
  • \n
  • \n
  • \n
  • \n
  • New design has following attribute - extra relation, bi-directional\nAlso a list of tweets\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • The new API is follows(person) instead of add_follower(person)\nowynn = Person.new("Owynn")\nunclebob = persons[0].followers[1]\nowynn.follows(unclebob) instead of below\nunclebob.add_follower(owynn)\n
  • abort transaction\nchange username and refresh in 2nd vm\nnot same as just returning cached instance in vm like other ORM’s\n
  • abort transaction\nchange username and refresh in 2nd vm\nnot same as just returning cached instance in vm like other ORM’s\n
  • abort transaction\nchange username and refresh in 2nd vm\nnot same as just returning cached instance in vm like other ORM’s\n
  • abort transaction\nchange username and refresh in 2nd vm\nnot same as just returning cached instance in vm like other ORM’s\n
  • abort transaction\nchange username and refresh in 2nd vm\nnot same as just returning cached instance in vm like other ORM’s\n
  • abort transaction\nchange username and refresh in 2nd vm\nnot same as just returning cached instance in vm like other ORM’s\n
  • abort transaction\nchange username and refresh in 2nd vm\nnot same as just returning cached instance in vm like other ORM’s\n
  • abort transaction\nchange username and refresh in 2nd vm\nnot same as just returning cached instance in vm like other ORM’s\n
  • abort transaction\nchange username and refresh in 2nd vm\nnot same as just returning cached instance in vm like other ORM’s\n
  • abort transaction\nchange username and refresh in 2nd vm\nnot same as just returning cached instance in vm like other ORM’s\n
  • abort transaction\nchange username and refresh in 2nd vm\nnot same as just returning cached instance in vm like other ORM’s\n
  • abort transaction\nchange username and refresh in 2nd vm\nnot same as just returning cached instance in vm like other ORM’s\n
  • abort transaction\nchange username and refresh in 2nd vm\nnot same as just returning cached instance in vm like other ORM’s\n
  • abort transaction\nchange username and refresh in 2nd vm\nnot same as just returning cached instance in vm like other ORM’s\n
  • abort transaction\nchange username and refresh in 2nd vm\nnot same as just returning cached instance in vm like other ORM’s\n
  • abort transaction\nchange username and refresh in 2nd vm\nnot same as just returning cached instance in vm like other ORM’s\n
  • abort transaction\nchange username and refresh in 2nd vm\nnot same as just returning cached instance in vm like other ORM’s\n
  • abort transaction\nchange username and refresh in 2nd vm\nnot same as just returning cached instance in vm like other ORM’s\n
  • abort transaction\nchange username and refresh in 2nd vm\nnot same as just returning cached instance in vm like other ORM’s\n
  • abort transaction\nchange username and refresh in 2nd vm\nnot same as just returning cached instance in vm like other ORM’s\n
  • abort transaction\nchange username and refresh in 2nd vm\nnot same as just returning cached instance in vm like other ORM’s\n
  • abort transaction\nchange username and refresh in 2nd vm\nnot same as just returning cached instance in vm like other ORM’s\n
  • abort transaction\nchange username and refresh in 2nd vm\nnot same as just returning cached instance in vm like other ORM’s\n
  • To understand the utility of read locks, imagine that you need to compute the average age of a large number of employees. While you are reading the employees and computing the average, another user changes an employee’s age and commits (in the aftermath of the birthday party). You have now performed the computation using out-of-date information. You can prevent this frustration by read-locking the employees at the outset of your transaction; this prevents changes to those objects.\nNOTEIf you have a read lock on an object and you try to write that object, your attempt to commit that transaction will fail. \n
  • To understand the utility of read locks, imagine that you need to compute the average age of a large number of employees. While you are reading the employees and computing the average, another user changes an employee’s age and commits (in the aftermath of the birthday party). You have now performed the computation using out-of-date information. You can prevent this frustration by read-locking the employees at the outset of your transaction; this prevents changes to those objects.\nNOTEIf you have a read lock on an object and you try to write that object, your attempt to commit that transaction will fail. \n
  • To understand the utility of read locks, imagine that you need to compute the average age of a large number of employees. While you are reading the employees and computing the average, another user changes an employee’s age and commits (in the aftermath of the birthday party). You have now performed the computation using out-of-date information. You can prevent this frustration by read-locking the employees at the outset of your transaction; this prevents changes to those objects.\nNOTEIf you have a read lock on an object and you try to write that object, your attempt to commit that transaction will fail. \n
  • Write locks are useful, for example, if you want to change the addresses of a number of employees. If you write-lock the employees at the outset of your transaction, you prevent other sessions from modifying one of the employees and committing before you can finish your work. This guarantees your ability to commit the changes.\n
  • Write locks are useful, for example, if you want to change the addresses of a number of employees. If you write-lock the employees at the outset of your transaction, you prevent other sessions from modifying one of the employees and committing before you can finish your work. This guarantees your ability to commit the changes.\n
  • Write locks are useful, for example, if you want to change the addresses of a number of employees. If you write-lock the employees at the outset of your transaction, you prevent other sessions from modifying one of the employees and committing before you can finish your work. This guarantees your ability to commit the changes.\n
  • Write locks are useful, for example, if you want to change the addresses of a number of employees. If you write-lock the employees at the outset of your transaction, you prevent other sessions from modifying one of the employees and committing before you can finish your work. This guarantees your ability to commit the changes.\n
  • create in one vm\nexecute in another vm\nhttp://maglev.github.com/docs/learn.html\n
  • create in one vm\nexecute in another vm\nFull credit to Monty / GemStone - see URL\nhttp://maglev.github.com/docs/learn.html\n\nThreads cannot be persisted by reference (because the JIT may have have compile methods to machine code, which cannot be ported across VMs), but we can use a trick.\nWhat did we do here? Well, we started a thread and created a continuation. A continuation captures the state of a computation, effectively copying the stack at the point it was created (We can see in the inspection output that the continuation has a reference to a copy of the Thread that created it). We assign the continuation to a global variable for convenience, and then commit it to the Stone repository.\n\n
  • create in one vm\nexecute in another vm\nFull credit to Monty / GemStone - see URL\nhttp://maglev.github.com/docs/learn.html\n
  • abort transaction\nchange username and refresh in 2nd vm\nnot same as just returning cached instance in vm like other ORM’s\n
  • abort transaction\nchange username and refresh in 2nd vm\nnot same as just returning cached instance in vm like other ORM’s\n
  • abort transaction\nchange username and refresh in 2nd vm\nnot same as just returning cached instance in vm like other ORM’s\n
  • abort transaction\nchange username and refresh in 2nd vm\nnot same as just returning cached instance in vm like other ORM’s\n
  • abort transaction\nchange username and refresh in 2nd vm\nnot same as just returning cached instance in vm like other ORM’s\n
  • abort transaction\nchange username and refresh in 2nd vm\nnot same as just returning cached instance in vm like other ORM’s\n
  • abort transaction\nchange username and refresh in 2nd vm\nnot same as just returning cached instance in vm like other ORM’s\n
  • \n
  • \n
  • Maglev Rubyfuza, Cape Town, 2012

    1. 1. Exploring Maglev Rudi Engelbrecht Rubyfuza, Cape Town, 2-3 Feb 2012lautus
    2. 2. MagLev History Rubyfuza - Cape Town - 2012
    3. 3. MagLev History • Smalltalk Virtual Machine Rubyfuza - Cape Town - 2012
    4. 4. MagLev History • Smalltalk Virtual Machine • Mature, used in production, large sites Rubyfuza - Cape Town - 2012
    5. 5. MagLev History • Smalltalk Virtual Machine • Mature, used in production, large sites • GemStone Rubyfuza - Cape Town - 2012
    6. 6. MagLev History • Smalltalk Virtual Machine • Mature, used in production, large sites • GemStone • Transactional Memory Object Server for Smalltalk Rubyfuza - Cape Town - 2012
    7. 7. MagLev History • Smalltalk Virtual Machine • Mature, used in production, large sites • GemStone • Transactional Memory Object Server for Smalltalk • Maglev Rubyfuza - Cape Town - 2012
    8. 8. MagLev History • Smalltalk Virtual Machine • Mature, used in production, large sites • GemStone • Transactional Memory Object Server for Smalltalk • Maglev • Transactional Memory Object Server for Ruby Rubyfuza - Cape Town - 2012
    9. 9. MagLev Concepts Rubyfuza - Cape Town - 2012
    10. 10. MagLev Concepts • Root Object Rubyfuza - Cape Town - 2012
    11. 11. MagLev Concepts • Root Object • Persistency by Reachability Rubyfuza - Cape Town - 2012
    12. 12. MagLev Concepts • Root Object • Persistency by Reachability • transitive closure Rubyfuza - Cape Town - 2012
    13. 13. MagLev Concepts • Root Object • Persistency by Reachability • transitive closure • Repository Rubyfuza - Cape Town - 2012
    14. 14. MagLev Concepts • Root Object • Persistency by Reachability • transitive closure • Repository • Ruby Virtual Machines Rubyfuza - Cape Town - 2012
    15. 15. MagLev Concepts • Root Object • Persistency by Reachability • transitive closure • Repository • Ruby Virtual Machines • local vs remote virtual machines Rubyfuza - Cape Town - 2012
    16. 16. MagLev Concepts • Root Object • Persistency by Reachability • transitive closure • Repository • Ruby Virtual Machines • local vs remote virtual machines • Garbage Collector Rubyfuza - Cape Town - 2012
    17. 17. MagLev Concepts Rubyfuza - Cape Town - 2012
    18. 18. MagLev Concepts • Transparent Object Persistence Rubyfuza - Cape Town - 2012
    19. 19. MagLev Concepts • Transparent Object Persistence • Large Object Space Rubyfuza - Cape Town - 2012
    20. 20. MagLev Concepts • Transparent Object Persistence • Large Object Space • limited by disk space (not RAM) Rubyfuza - Cape Town - 2012
    21. 21. MagLev Concepts • Transparent Object Persistence • Large Object Space • limited by disk space (not RAM) • Multi-user Rubyfuza - Cape Town - 2012
    22. 22. MagLev Concepts • Transparent Object Persistence • Large Object Space • limited by disk space (not RAM) • Multi-user • Thousands of virtual machines Rubyfuza - Cape Town - 2012
    23. 23. MagLev Concepts • Transparent Object Persistence • Large Object Space • limited by disk space (not RAM) • Multi-user • Thousands of virtual machines • Sharing one object space Rubyfuza - Cape Town - 2012
    24. 24. MagLev Concepts • Transparent Object Persistence • Large Object Space • limited by disk space (not RAM) • Multi-user • Thousands of virtual machines • Sharing one object space • Isolation of each user’s view (repeatable read) Rubyfuza - Cape Town - 2012
    25. 25. MagLev Concepts Rubyfuza - Cape Town - 2012
    26. 26. MagLev Concepts • Concurrency Rubyfuza - Cape Town - 2012
    27. 27. MagLev Concepts • Concurrency • Multi Version Concurrency Control Rubyfuza - Cape Town - 2012
    28. 28. MagLev Concepts • Concurrency • Multi Version Concurrency Control • Optimistic and Pessimistic models Rubyfuza - Cape Town - 2012
    29. 29. MagLev Concepts • Concurrency • Multi Version Concurrency Control • Optimistic and Pessimistic models • Stores any Ruby Object Rubyfuza - Cape Town - 2012
    30. 30. MagLev Concepts • Concurrency • Multi Version Concurrency Control • Optimistic and Pessimistic models • Stores any Ruby Object • including it’s code (methods) Rubyfuza - Cape Town - 2012
    31. 31. Ruby VM Ruby VM Shared Page Repository CacheRuby VMRuby VM
    32. 32. Ruby VM RepositoryRuby VM
    33. 33. MagLev - Magic Hat Rubyfuza - Cape Town - 2012
    34. 34. MagLev - Magic Hat • Rabbit in Hat Trick Rubyfuza - Cape Town - 2012
    35. 35. class Person attr_accessor :username, :followers def initialize(username) @username = username @followers = Array.new end def add_follower(person) @followers << person end def remove_follower(person) @followers.delete(person) end def to_s result = "@#{@username} --> [#{@followers.size}]" @followers.each {|f| result = result + " #{f.username}" } result endend Rubyfuza - Cape Town - 2012
    36. 36. class Person attr_accessor :username, :followers def initialize(username) @username = username @followers = Array.new end ...end Rubyfuza - Cape Town - 2012
    37. 37. ... def add_follower(person) @followers << person end def remove_follower(person) @followers.delete(person) end... Rubyfuza - Cape Town - 2012
    38. 38. ... def to_s result = "@#{@username} --> [#{@followers.size}]" @followers.each {|f| result = result + " #{f.username}" } result end... Rubyfuza - Cape Town - 2012
    39. 39. Maglev.persistent do require personendMaglev::PERSISTENT_ROOT[:persons] = Array.newMaglev.commit_transaction Rubyfuza - Cape Town - 2012
    40. 40. person.rb
    41. 41. person.rbperson.rb
    42. 42. :persons Array person.rbperson.rb
    43. 43. :persons Array :persons Array person.rb person.rbperson.rb
    44. 44. persons = Maglev::PERSISTENT_ROOT[:persons]persons.each {|p| puts p} Rubyfuza - Cape Town - 2012
    45. 45. require persondhh = Person.new("dhh")obie = Person.new("obie")unclebob = Person.new("unclebob")noob1 = Person.new("noob1")noob2 = Person.new("noob2")dhh.add_follower(obie)dhh.add_follower(unclebob)obie.add_follower(unclebob)unclebob.add_follower(noob1)unclebob.add_follower(noob2)persons = Maglev::PERSISTENT_ROOT[:persons]persons << dhhpersons << obiepersons << unclebobMaglev.commit_transaction Rubyfuza - Cape Town - 2012
    46. 46. :persons Array :persons Array
    47. 47. :persons Arraydhh :persons Array
    48. 48. :persons Arraydhh obie :persons Array
    49. 49. :persons Arraydhh obie :persons unclebob Array
    50. 50. :persons Arraydhh obie :persons unclebob Array
    51. 51. :persons Arraydhh obie :persons unclebob Array
    52. 52. :persons Arraydhh obie :persons unclebob Array
    53. 53. :persons Arraydhh obie :persons unclebob Array noob1
    54. 54. :persons Arraydhh obie :persons unclebob Array noob1 noob2
    55. 55. :persons Arraydhh obie :persons unclebob Array noob1 dhh obie noob2 unclebob noob1 noob2
    56. 56. TwitterClone2 Rubyfuza - Cape Town - 2012
    57. 57. TwitterClone2 • Improved design Rubyfuza - Cape Town - 2012
    58. 58. TwitterClone2 • Improved design • Multiple VM’s Rubyfuza - Cape Town - 2012
    59. 59. TwitterClone2 • Improved design • Multiple VM’s • Concurrent access - MVCC Rubyfuza - Cape Town - 2012
    60. 60. TwitterClone2 • Improved design • Multiple VM’s • Concurrent access - MVCC • First commit wins Rubyfuza - Cape Town - 2012
    61. 61. class Person attr_accessor :username, :email, :followers, :following, :tweets def initialize(username) @username = username @email = username + “@email.com” @followers = Array.new @following = Array.new @tweets = Array.new end ...end Rubyfuza - Cape Town - 2012
    62. 62. ... def follows(person) @following << person person.add_follower(self) end def unfollows(person) @following.delete(person) person.remove_follower(self) end... Rubyfuza - Cape Town - 2012
    63. 63. ... def add_follower(person) @followers << person end def remove_follower(person) @followers.delete(person) end... Rubyfuza - Cape Town - 2012
    64. 64. ... def tweets(text) @tweets << Tweet.new(self, text) end... Rubyfuza - Cape Town - 2012
    65. 65. ... def to_s result = "@#{@username} tweeted #{@tweets.size} times, follows #{@following.size} persons and is followed #{@followers.size} times" result = result + " , following: {" @following.each {|f| result = result + " #{f.username}"} result = result + " }" result = result + " followed by: {" @followers.each {|f| result = result + " #{f.username}"} result = result + " }" result end... Rubyfuza - Cape Town - 2012
    66. 66. Maglev.persistent do require person require tweetendMaglev::PERSISTENT_ROOT[:persons] = Array.newMaglev.commit_transaction Rubyfuza - Cape Town - 2012
    67. 67. persons = Maglev::PERSISTENT_ROOT[:persons]persons.each {|p| puts p} Rubyfuza - Cape Town - 2012
    68. 68. require persondhh = Person.new("dhh")obie = Person.new("obie")unclebob = Person.new("unclebob")noob1 = Person.new("noob1")noob2 = Person.new("noob2")obie.follows(dhh)unclebob.follows(dhh)unclebob.follows(obie)noob1.follows(unclebob)noob2.follows(unclebob)persons = Maglev::PERSISTENT_ROOT[:persons]persons << dhhpersons << obiepersons << unclebobMaglev.commit_transaction Rubyfuza - Cape Town - 2012
    69. 69. dhh obie followers dhh followers obie following following unclebob followers dhhConcurrent updates (in different VM’s) following to same object fails
    70. 70. dhh obie followers dhh followers obie following following unclebob followers dhhConcurrent updates (in different VM’s) following to same object fails
    71. 71. :persons Array dhh obie followers dhh followers obiedhh obie following following unclebob noob1 noob2 unclebob followers dhh Concurrent updates (in different VM’s) following to same object fails
    72. 72. :persons Array dhh obie followers dhh followers obiedhh obie following following unclebob noob1 noob2 unclebob followers dhh Concurrent updates (in different VM’s) following to same object fails
    73. 73. :persons Array dhh obie followers dhh followers obiedhh obie following following unclebob noob1 noob2 unclebob followers dhh Concurrent updates (in different VM’s) following to same object fails
    74. 74. :persons Array dhh obie followers dhh followers obiedhh obie following following unclebob noob1 noob2 unclebob followers dhh Concurrent updates (in different VM’s) following to same object fails
    75. 75. MagLev - Locks Rubyfuza - Cape Town - 2012
    76. 76. MagLev - Locks • Read lock on object Rubyfuza - Cape Town - 2012
    77. 77. MagLev - Locks • Read lock on object • Use object’s value and commit without fear that some other transaction has committed a new value for that object during your transaction Rubyfuza - Cape Town - 2012
    78. 78. MagLev - Locks • Read lock on object • Use object’s value and commit without fear that some other transaction has committed a new value for that object during your transaction • Guarantees that other sessions cannot: a) acquire a write lock on the object b) commit if they have written the object Rubyfuza - Cape Town - 2012
    79. 79. MagLev - Locks Rubyfuza - Cape Town - 2012
    80. 80. MagLev - Locks • Write lock on object Rubyfuza - Cape Town - 2012
    81. 81. MagLev - Locks • Write lock on object • Guarantees that you can write the object and commit. Rubyfuza - Cape Town - 2012
    82. 82. MagLev - Locks • Write lock on object • Guarantees that you can write the object and commit. • Guarantees that other sessions cannot: a) acquire a read or write lock on the object b) commit if they have written the object Rubyfuza - Cape Town - 2012
    83. 83. MagLev - Locks • Write lock on object • Guarantees that you can write the object and commit. • Guarantees that other sessions cannot: a) acquire a read or write lock on the object b) commit if they have written the object • Only one session can hold a write lock on an object - no other session can hold any kind of lock on the object. Rubyfuza - Cape Town - 2012
    84. 84. MagLev - Procs y = 4 proc = Proc.new {|x| x * y} proc.call(4) Rubyfuza - Cape Town - 2012
    85. 85. MagLev - Continuation Thread.start { callcc {|cc| $cont = cc}; p “Run afterOne pretty callcc” } Maglev::PERSISTENT_ROOT[:cc] = $cont Maglev.commit_transaction Rubyfuza - Cape Town - 2012
    86. 86. MagLev - Continuation Maglev.abort_transaction $cont = Maglev::PERSISTENT_ROOT[:cc] Thread.start {$cont.call} Rubyfuza - Cape Town - 2012
    87. 87. MagLev - Summary Rubyfuza - Cape Town - 2012
    88. 88. MagLev - Summary • Rabbit in hat trick Rubyfuza - Cape Town - 2012
    89. 89. MagLev - Summary • Rabbit in hat trick • Concurrent access to objects in distributed VM’s Rubyfuza - Cape Town - 2012
    90. 90. MagLev - Summary • Rabbit in hat trick • Concurrent access to objects in distributed VM’s • Proc’s can be persisted Rubyfuza - Cape Town - 2012
    91. 91. MagLev - Summary • Rabbit in hat trick • Concurrent access to objects in distributed VM’s • Proc’s can be persisted • references enclosing environment’s variables Rubyfuza - Cape Town - 2012
    92. 92. MagLev - Summary • Rabbit in hat trick • Concurrent access to objects in distributed VM’s • Proc’s can be persisted • references enclosing environment’s variables • Continuations Rubyfuza - Cape Town - 2012
    93. 93. MagLev - Summary • Rabbit in hat trick • Concurrent access to objects in distributed VM’s • Proc’s can be persisted • references enclosing environment’s variables • Continuations • Queue Rubyfuza - Cape Town - 2012
    94. 94. MagLev - Summary • Rabbit in hat trick • Concurrent access to objects in distributed VM’s • Proc’s can be persisted • references enclosing environment’s variables • Continuations • Queue • see example on github/maglev Rubyfuza - Cape Town - 2012
    95. 95. Credits Monty Williams GemStone http://maglev.github.com/docs/learn.html https://github.com/MagLev/maglev Conrad Taylor Playing with Maglev the Ruby VM http://www.conradtaylor.com/2011/11/08/playing-with-maglev-the- ruby-vm/ Tim Felgentreff Debugging on Steroids - what Ruby should learn from Smalltalk http://blog.bithug.org/2011/09/maglev-debug Rubyfuza - Cape Town - 2012
    96. 96. Questions • Updates on Twitter @rudiengelbrecht • Slides on SlideShare • Source code on GitHub userid - rle Rubyfuza - Cape Town - 2012

    ×