Saturday 15 March 2014

Simple Grails 2.3+ service for managing a collection taking into account multiple requests -



Simple Grails 2.3+ service for managing a collection taking into account multiple requests -

i create service manage collection through rest-style controller. thinking required create service safe multiple people hitting @ same time.

so this...

@transactional class noteservice { private static users = [:] //this won't simple future private static key = 0; def get(id) { log.debug("we within get") homecoming users[id] } def create(obj){ log.debug("we within create") update(key++, obj) } def update(id, obj){ log.debug("we within update") users.put(id,obj) } def delete(id){ log.debug("we within remove") user.remove(id) } }

will work if have multiple controller requests hitting @ same time? concerns there problems if 2 clients trying nail @ same time. there improve strategy maybe using promises? using 2.3+

no, broken , not thread-safe.

if have no mutable state, thread-safe. of course of study if have no state variables @ it's better, it's fine have state variables things dependency-injected spring beans, or logger, etc. long don't alter values, they're immutable (they set during startup , aren't changed afterwards), , 2 concurrent callers won't interfere each other.

but have thing problematic concurrent access - state variable (in case doesn't help or wound it's static because default grails services singleton spring beans, map non-static instance variable , have same problems) alter in multiple methods.

the easiest thing synchronize on map. can't synchronize methods - work if 1 method accessed map. using synchronized serialize calls , guarantee no concurrent access. read , write multiple methods, serializing calls each of doesn't help interactions between concurrent calls of different methods. if synchronize every method still have occasional instances 2 methods called @ same time; beingness synchronized doesn't help.

so need mechanism synchronize across methods, , you're lucky here since have 1 mutable field, can synchronize on (but of course of study create dummy 'lock' object , synchronize on if had multiple fields beingness changed). access methods (whether they're synchronized or not, , can un-synchronize them because that's slowing things down) guarded serializing calls "through" map.

this easiest, isn't performant. if time spent holding each synchronization lock short, won't notice much of issue. seek create synchronized blocks short possible:

def update(id, obj) { log.debug("we within update") synchronized(users) { users.put(id,obj) } }

a much improve solution utilize java.util.concurrent.* locking , concurrency classes added in java 5. performant if implemented correctly, getting point understand how utilize these apis take while. best resource java concurrency in practice. written in 2006 still applicable (it doesn't include updates in newer jdks, apis available in 1.5 , described in book sufficient many utilize cases). book ~400 pages material hard (but explained), plan on multi-month time frame :)

venkat subramaniam's programming concurrency on jvm great resource. it's newer (2011) , less in-depth jcip, covers less more approachable. , covers multiple jvm languages including groovy. still multi-month timeframe, fewer months.

grails

No comments:

Post a Comment