Hi Danijel, I think your description of the expected behavior of Trident primitives is correct. I'm interested in understanding the issue you describe, could you share some code so we can have a look?
Svend On Thu, Feb 13, 2014 at 9:20 PM, Danijel Schiavuzzi <[email protected]>wrote: > Hi, > > I'm experimenting a little with a TridentState implementation which > persists state in a RDBMS (SQL) database, and it's working fine using > paralellismHint(1). > > However, increasing the TridentState paralellism leads to database > deadlocks, which is unusual since I thought that, by using groupBy() before > persistentAggregate(), I was making sure that every TridentState instance > receives a stream of distinct values at any given point in time -- so that > every instance updates those distinct keys in the database (i.e. distinct > table rows), thus avoiding any database concurrency issues. Apparently, > this does not work as intended. > > Before I continue my research any further, I'd welcome any info or hint on > avoiding these deadlocks. Should I improve my TridentState implementation > somewhere? I see that the State is passed the partitionIndex and > numPartition parameters on initialization, which I currently don't use -- > and which I suppose are the key to implementing paralellism right? > > Also, could you recommend an example TridentState implementation which got > the paralellism right? > > Any help is appreciated, > > -- > Danijel Schiavuzzi >
