About transactions, you are right to notice that there is a similarity between Java Card transactions and database transactions. However, persistence in Java Card is embedded in the VM, and it is much simpler than for databases. Just look at a definition of ACID on wikipedia, and you will notice that the guarantees are quite complex.

The constructor is private on purpose, because I have defined a factory, and I want all allocations to go through it (mostly because there is a recycling mechanism).

About the constructor, you are right about the fact that a tear at the wrong time could lead to an unreachable object (the object is created before the invocation of its constructor, in all cases). What I mean by saying that the transaction is not mandatory is that there is no risk of inconcistency.

Overall, I must admit that this example is too simple to correctly explain transactions. Better examples should come when we will cover the protection of the data’s integrity, a few weeks or months from now.

About deletion, you are right. However, I will cover this in a separate post.

Finally, about the search method, yes, there is an issue about the initialization of the field, because the code presented in the JC101-4C post is incomplete. I will fix that.

Some remarks:
– Why is JC’s transaction mechanism not comparable with the database one? To me it’s pretty the same concept, but maybe I misunderstood something ..
– Did you declare the constructor private on purpose? I thought it must be at least protected, otherwise it cannot called directly, and only usable from within the factory method getInstance().
– In the PasswordEntry constructor you mention that the transaction mechanism is not required. What if there is a tear between next = first ; and first = this ;? Is the instance created? If yes, this instance is connected to the list, but not retrievable because ‘first’ is the only entry point.
– In your deletion mechanism you take only the recycle scenario into account. Thus in case of a lot of deletion the memory space is always occupied. What if the user wants to free up memory space? It could be accomplished with e.g. a parameter for the delete method: boolean deleteObject –> in the delete method check if object deletion is supported, set pe == null and apply for the object deletion mechanism.
– The search method uses the variable pe.idLength, but you do not initialize this field in the PasswordEntry constructor, not in the getInstance() method.

rgds
Igor