I am very new to CSLA and am working my way through a number of basic issues for my business objects. One issue for me is the management of temporary object ids.
I have been reviewing the posts on this site regarding Guids, CombGuids, Integers, etc. The debate is clearly lively and very interesting. In my current situation, however, I must use integer ids. Given this requirement, I am trying to find a thread-safe way of managing temporary integer object ids prior to saving new objects to the database.
Below is my attempt at doing this. I have only included the elements of a class that pertain to managing the temporary object ids. Am I missing anything important?
using Csla;
[Serializable()]
public class MyObject : Csla.BusinessBase<MyObject>
{
//This is the static property used by all instances of this class.
private static int _lastTempId = 0;
//This is the object id of the instance.
private int _id;
protected override object GetIdValue()
{
//Return the object id of the instance
return _id;
}
protected override void DataPortal_Create()
{
//Set the object id of the instance to _lastTempId - 1. If, by some strange circumstance
//there are enough objects of this type instantiated such that _lastTempId reaches the
//minimum possible value for Int32, then _lastTempId is reset to 0. If this is not done,
//then Interlock.Decrement will cycle from -2147483648 to 2147483647. I want
//my object ids to be negative at all times.
if (_lastTempId == -2147483648)
{
System.Threading.Interlocked.Exchange(ref _lastTempId, 0);
}
_id = System.Threading.Interlocked.Decrement(ref _lastTempId);
}
protected override void DataPortal_Insert()
{
//Code to insert data into database contains an output parameter for the ScopeIdentity.
//The object id is set to this ScopeIdentity, overriding the previous temporary id.
_id = (int)myCommand.Parameters("@newId").Value;
}
}
Any comments would be appreciated.
Thank you Bayu and Brian for your quick responses.
I can see that I have more to learn :)
Both of your points are well taken. I believe that Brian's code example resolves the thread-safety issues that Bayu raised. Additionally, I like the idea of subclassing BusinessBase to provide temporary ids across all business objects. However, the issue that is most glaring to me now is the reboot and reset issue, which can cause objects of the same class to have the same ids. I realize that ids can be managed through the database. However, I was hoping to come up with a solution that would not require a hit to the database for every object created, regardless of whether or not it will be saved to the database. Maybe this is not such a big deal.
What are your thoughts?
I am seriosly contemplating moving to CombGuids. However, I am particularly concerned about providing data to 3rd party vendors. I am not yet comfortable that providing a CombGuid will be practical.
It isn't that hard though!
Interlocked.Decrement returns the resulting value, and it is threadsafe.
DataPortal_Create() is threadsafe, because it is running in an instance on a single thread. While other objects may be created at the same time, they'll run their own DP_Create() methods.
So you only need to worry about that one bit of shared state, and you can use Interlocked.Decrement() to use it:
private static int _lastId;
private void DataPortal_Create(Criteria criteria)
{
_id = Interlocked.Decrement(_lastId);
}
No global locking required or anything fancy at all.
Sorry, I see that you are worried about the possibility that your appdomain will continue to exist long enough to create a few trillion objects of this particular type... I missed that on the first pass reading the question.
My response: are you serious? ![Big Smile [:D]](/emoticons/emotion-2.gif)
I realize that such a thing is hypothetically possible. And perhaps your app really could cause this to happen. But you really need to evaluate whether it is possible in reality for the app to try and create a few trillion Customer objects (for example) within the lifetime of a single appdomain.
If so, then do the extra work, and take the extra perf hit, to avoid the problem.
But 99.999% of the time this is impossible in any real sense. So how can you justify the complexity cost and perf hit to avoid something that can't actually happen?
Hi Rocky,
I agree with you. I am not concerned about the application being in existence long enough to reassign a duplicate ID. I was contemplating the possibility of reboots/resets, as posed by Bayu. In these cases, the application would not necessarily have to completely cycle through to assign a duplicate id. Although, I would concede that the probabilty of reassignment of a duplicate id due to reboot/reset is no doubt very low.
BTW, I think it is so cool that you participate in these forums. The fact that you take the time to address Newbie questions (like mine) is a testament to your commitment to the product. I was initially exposed to CSLA at version 1.5. I found it to be quite impressive and have been waiting for an opportunity to implement it. Finally, at version 2.1.4, I have that opportunity.
The duplicate id issue can only happen in limited scenarios –
probably not ones you will encounter – or at least ones you can avoid.
Remember that the id only needs to be unique within a given
object graph – not application-wide. Certainly not cross-user, and not
even within the context of a single user, except in ONE SPECIFIC COLLECTION.
So the only time you could get into trouble is if you have an
object graph to which you are adding new items, and somehow you end up adding
two items to one specific collection in that object graph with duplicate ID
values.
This can’t happen if you are generating the temporary IDs
on the client machine (smart client or web server), because any failure on that
machine or appdomain would cause all those objects to have been lost too. In
other words, the loss of _lastId automatically goes hand-in-hand with the loss
of the whole object graph.
It CAN happen if you are generating the temporary IDs on a
shared application server. In other words, your DataPortal.Create() call
actually goes across the network to an app serve to create and initialize the
new object. In that case, were the app server to fail and reload during the
time a user is interacting with an object graph on the client, it would be
possible to get a duplicate id within that object graph.
The only way to avoid that is to use an ID allocation scheme
that relies on a persistent store. Remember that if that shared app server
resets, anything in memory is gone. The only way to know the REAL _lastId value
is if it was persisted somewhere. It is almost never performant to load one
integer just to increment it, so what ID allocation algorithms have done for
decades is to allocate a block of ID values.
In other words, the app server does a db call to allocate, say,
100 IDs. The db now has a “lastId” value of -100, but the app
server, in memory, as _lastId of 0. The app server keeps decrementing that in
memory value until it hits -100, then it goes back to the db to get another
block. At that point the db has a “lastId” of -200 and the process
repeats.
If the app server crashes, or even is shut down normally, when
it restarts it goes to the db and asks for another allocation. This typically
leaves holes, because the only “safe” lastId probably isn’t
the REAL lastId. But for temp IDs no one cares really.
None of that really deals with threading – threading is
the smallest part of the issue really. And honestly, most apps don’t
encounter this issue, because they allocate the temp ID values on the client
and avoid the whole issue.
Even if you are initializing new objects on an app server, you
can allocate the temp ID on the client (in your factory method) and pass it to
the app server through the criteria object. That is typically far simpler than
implementing a persisted ID allocation algorithm.
Rocky
RockfordLhotka: