0

I currently have a set of rules to create usernames based on a user's initials. This is not adjustable. So a user has 'xxx' as his initials. His username would be zzxxx1. The next user with the same initials would be zzxxx2 and so on. I'm using Java to generate the ids (useridCreation.jar). This jar is being called by a multi-threaded application (ITIM). So how would I go about reserving zzxxx1 until the first user is finished being created so as to not have duplicate usernames. This is a feed type situation where the usernames are being generated. I can pull up to 4 users/sec. I was thinking Vector, but I'm not too familiar with multi-threaded applications so I'm not sure how to approach that. SQL table is another option, but I feel like even with concurrent writing off, there would be some issues there. What about a file that I lock/unlock. Has anybody implemented a solid solution for this type of issue?

Edit: I forgot to mention this is a cluster environment.

pnkflydgr
  • 665
  • 3
  • 13
  • 22

1 Answers1

2

This jar is being called by a multi-threaded application (ITIM). So how would I go about reserving zzxxx1 until the first user is finished being created so as to not have duplicate usernames.

If this is a cluster configuration (i.e. distributed applications running on multiple servers) then you are going to have to have some sort of central service that guarantees the uniqueness of the names. One easy solution would be a database with unique constraints on the username field in some table. Each server could do something like an ordered LIKE query to find the highest username number and then try to create an entry using the next number. If it was taken it would try again with the next number...

Another solution would be to have a central service which does the uniqueness guarantee. All of the cluster nodes would contact the central one which would use a synchronized or other lock to ensure that only one thread is generating a unique name at a time. Then again I assume you need persistence so maybe the database is the easiest option.

Gray
  • 115,027
  • 24
  • 293
  • 354
  • Well my initial "reserved" check is the user directory (ldap). So I would only need persistence until the user record is created in the ldap. I really like the service based synchronized approach. But like you said the the db would be easier and I'm quickly running out of hours for this project. Thanks so much for your time. – pnkflydgr Sep 05 '13 at 17:21