All in all, this looks like a much better method of doing things, and it will help me keep to my goal of 100% CMP. Plus, if it persisted it's last number used, as long as the next number didn't exist response time would still be fast, given this scenario:
This code represents the ID column of the TICKET table after several closed tickets have been purged off: | | 1 | 2 | 3 | 5 | 6 | 7 | 21 | 22 | When first deployed, the first ticket would have a longer response time than the second because the bean would have to query by primary key for 1, 2, 3, and 4 before it found four open. On the next request for a number it would have to query 5, 6 and 7 before it found 8 open. The subsequent requests up to 20 would be fast because all those slots are open. Then once lastUsedNumber reaches 23, it's wide open for new ticket numbers. How would this design handle simultaneous requests? I tested the singleton design and I was unable to get duplicate keys so I'm reasonably sure the singleton bean blocked requests until it could complete them sequentially. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3840508#3840508 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3840508 ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
