ejb timers currently use UUID as their timer id, and primary key when persisted to database. There are some drawbacks with UUID-based timer id:

• expensive to generate
• very long, and not human-readable
• takes too much memory space to cache the id fields large number of timers
• UUID values are all random and hinders database operations like insertion, indexing, retrieving.
• UUID version 4, which is the one used in timer id, is not 100% guaranteed to be globally unique, though duplicates are unlikely. See UUID Wikipedia collision section. "...collisions can occur even without implementation problems, albeit with a probability so small that it can normally be ignored...the probability to find a duplicate within 103 trillion version-4 UUIDs is one in a billion." 

In a related issue, WFLY-15568 explores the possibility of switching to an int-based timer id, but that will not work with existing implementation and timers, which use string timer id. Int timer id can be a long-term task.

In the meantime, we should be able to design a string-based timer id, and avoid the above drawbacks at the same time, and still be fully compatible with existing implementation and timers.