thanx ppl. Peter, you've got it in one. We're probably going to remove stale/orphaned "locks" everytime one is [attempted to be] set or released. But what you've got is pretty much the idea. Cheers.
It's a toss-up whether to go with a struct'o'structs or a query. the query will be easier to do a Q'o'Q to find old or orphaned locks but to remove them it'll be copying the query into a new query and deleting the origional. Structs have structDelete()...hmmm... and while Mark made a good point about queries (java hashtable), arrays (java vectors), structs (hashtable?) being intrinsically thread safe, it's the couple of lines of processing code (check if already exists, delete stale ones, etc) around the add/delete that has me "concerned". Is the "no need for a CFLOCK" still applicable? this turned out to be an interesting read: http://www-106.ibm.com/developerworks/java/library/j-jtp09263.html ("Thread safety is not an all-or-nothing proposition") Arron: yeah they seem like good reasons and I'm begining to like the idea of hiding the CFLOCK implementation within the method - one less thing for the programmer (ie: me) to get wrong. I was just worried I was taking abstraction too far. Good point about performance - it's going to be a bit of a bottleneck anyhoo... thanx again for your help cheers barry.b ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
