@Edward & Matt Yes, I'd be happy to add this info to the wiki. I just need to check a few things before I do. I'm thinking that I got some different results when using the cfapplication tag as opposed to using cfscript. I could be mistaken because I was trying a lot of different things at the time, so I would like to recheck that before I update the wiki.
@Vince Thanks, would have been stuck without your help! @all This might not be the right thread, and can be moved to another if necessary. My question is is in regards to scalability, which somewhat relates to j2ee sessions. In my application, as in most, I am updating datastore entities from multiple locations in my application. These updates will be occurring to store aggregate data from other related entities. Such as a Post entity storing number of Comments or a Invoice entity storing the number of items and invoice total. I know that I could store an array in the Parent entity, but the Facebook application that I am building will be keeping track of user points and there, over time, would be a large number of child "transactions". I am afraid that this would overload the parent entity and also make it difficult to query Users, ordered by their point total. With that long-winded explanation out of the way. I am looking at locking the parent entity before updates so that I don't overwrite updates from multiple processes. I have considered the following: 1) Using a cflock with scope="Session". I think this would create a bottleneck in the application and would not protect updates from different parts of my application. 2) Using cflock with name="#googleKey#". This would protect an entity from different parts of the application, but, named locks are per server and fail across a cluster. It would be great if a named lock existed across the cluster, as sessions do. I am not a java person, so I don't know the complexities of making this happen,but , if it could be implemented as a core feature it would be very valuable in a massively scalable environment. It could be used to lock file writes, entity writes and finer grained session variable updates. I know ORM has been discussed before and there are a lot of differing opinions, but some sort of entity locking solution would at least allow someone to implement their own do-it-yourself ORM, or possibly be useful in a true ORM solution. If I am going in the wrong direction, or, reinventing the wheel because something already exists. Please let me know. Thanks, Adam -- Open BlueDragon Public Mailing List http://www.openbluedragon.org/ http://twitter.com/OpenBlueDragon mailing list - http://groups.google.com/group/openbd?hl=en !! save a network - please trim replies before posting !!
