Sorry for the very slow response. I was on vacation for a bit, then involved in other training, so I got a little out of the loop.
Thank you so much for the good input on how to set this up. I want to run this idea past you. Suppose I make a singleton bean that perisists to the database it's own primary key (since there is only of these) the last used Primary key of the ticket, and a boolean. Since purging off the old closed out tickets requires a concious decision by the administrator, it wouldn't be much overhead to flip that boolean value whenever a purge was completed. Using this method the bean, under normal circumstances would need to check to see if the "purged" bit is flipped. If that bit is flipped, it would set it's last used value to 0, and start from the begining. If the bit is not flipped it will pull it's last used value, increment it, and findByPrimaryKey() that value. If that value is found to exist, it would repeat the findByPrimaryKey() process until it found a value that was open. Then it would write that value to the last used value slot. If the table looked like: | | 1 | 2 | 3 | 4 | 5 | 6 | . | . | . | 998 | 999 | Then each access would take the same amount of time. If the table looked like this after a purge: | | 1 | 2 | 3 | 4 | 6 | 7 | . | . | 999 | With only the number 5 record being purged off, than the first primary key would be a little slow, the second would be noticably slow, and normal operation would continue after that. However, it has been my experience that when records are purged out of a helpdesk system the resultant database looks like this: | 10 | 227 | 501 | 550 | 700 | 720 | 730 | 740 | 750 | 760 | 770 | 780 | 790 | 800 | 805 | 810 | 815 | . | . | 990 | 991 | 992 | 993 | The closer you get to the more recently created tickets the more tickets numbers there are being used. I almost wish I had spent more time going to school than in the Marines, because I would really like to know how to do the arithmetic behind calculating min, max, and mean speed in this situation. I was bouncing about a couple more solutions in my head. The first would be to use some sort of time/date/sourceIP or Username hash to generate a psudo-random primary key that will not be duplicated. I'm afraid that may be beyond my experience though. The second is to use a ticket number prefix that is incremented every time a group of tickets are purged off. The end result would be ticket series 1-x, then a purge, then ticket series 2-x, then a purge, and so on. On purge, the bean that controls the purging would check to see if any tickets in the 1- series exists, and if not, use that prefix for the next series, etc. What are your thoughts on these alternatives? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3843453#3843453 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3843453 ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
