Modification Timestamps on Objects or Counters

1) I want to associate a modification time with my Objects.

2) These objects are not touched by other threads. They all run in the same thread.

3) But I need to know which one is the most recently modified.

4) I *cannot* have a situation where Object A and Object B return the same modification timestamp. Since everything is running in a single thread, the call to modify Object A must have occured either before OR after the call to modify Object B. It cannot have occured at the exact same time.

I am wondering if System.currentTimeMillis() is accurate enough? I need to know what I should use to set the modification timestamp. Object A.modified should NEVER equal Object B.modified, otherwise my program could produce wrong results.

So what's the best thing to use to set the timestamp?

hmm... I just think I answered my question partially while writing this... I guess a counter is a much better solution than a timestamp. So how would I implement a counter properly? Object A and Object B do not have any references to a global object where I can store the counter. They will usually be running in a multithreaded environment like a Servlet or JSP page. But they have no ability to access Servlet or JSP or any J2EE objects.

So where can I put a counter that I can access from Object A and Object B but where the counter cannot be influenced by other threads running in the same VM ?
ycompAsked:
Who is Participating?

[Webinar] Streamline your web hosting managementRegister Today

x
 
CEHJConnect With a Mentor Commented:
Assign the counter value on obtaining the object from the pool. If you want to make it mutable later, make the counter value mutable, but only by the mutator method of the object's attribute, e.g.

public void setX(String x) {
    this.x = x;
    mutationCount++;
}
0
 
petmagdyCommented:
make a collection of ur objects u want to monitor (like vector) and make a variable named most recently updated object that points to the last updated object
but make sure that any updates on this variable is synchronized
0
 
petmagdyCommented:
by this approch u will now only the most recently updated object, do u need more?
0
The new generation of project management tools

With monday.com’s project management tool, you can see what everyone on your team is working in a single glance. Its intuitive dashboards are customizable, so you can create systems that work for you.

 
ycompAuthor Commented:
thanks, it's a good suggestion but it won't work for what I'm doing.

My objects are floating around everywhere. Then near the end of my code I have to "resolve" them and compare their timestamps. I need to do this for certain groups of them. However, since they float around I don't know which will be each group until "resolve time". Sounds kind of weird but that's the best way I have to describe it.
0
 
ycompAuthor Commented:
sorry "which will be IN each group"
0
 
petmagdyCommented:
are the objects of the same class? or at least can they share a base class?
0
 
ycompAuthor Commented:
yes they share a base class
0
 
CEHJCommented:
You could use the Factory pattern to create the objects. The factory itself could be the controlling entity when it comes to grouping them or uniquely identifying them
0
 
petmagdyCommented:
then u can do this sort of monitoring on the base class something like this example:

public class BaseClass
{
   protected static BaseClass   theRecentModifiedObject = null;

  public static synchronized setRecentModifiedRecentObject(BaseClass theObject)
  {
    theRecentModifiedObject  = theObject;
  }
 
  public static theRecentModifiedObject getRecentModifiedRecentObject()
  {
     return theRecentModifiedObject;
  }
}

public class DerivedClass extends BaseClass
{
    public notifyMeModifed()
    {
           ......
           BaseClass.setRecentModifiedRecentObject(this);
    }
   
}
0
 
CEHJCommented:
In fact it'd be more than just a Factory pattern. It would have elements of the Facade pattern such that mutations to the objects could only be carried out through the Factory/Facade and therefore would be controllable and reliable
0
 
ycompAuthor Commented:
petmagdy, I guess I didn't explain myself well enough.

The BaseClass approach won't work because there are many groups of these objects.

I mean all DerivedClasses extend from BaseClass, this is true. However, there are many many groups of DerivedClass objects.

The Derived objects float in and out of these Groups. (e.g. Group A, B, C, D, etc.) and only at "resolve" time do we compare them to the other objects in the Group.

Derived objects reside usually in container objects. These are not the groups. Groups are relationships between the positions of some elements in a container objects and the positions of other elements of other container objects. derived objects swim in and out of the containers until "resolve time" at which point the actual groups are formed and the most recent derived object is each group is the "winner".
0
 
ycompAuthor Commented:
basically all I'm saying is that each object must keep track of it's own "modification" timestamp or current value of the "global" counter.
0
 
ycompAuthor Commented:
CEHJ, I guess I'll probably just use a factory pattern with a reference in each object back to the MasterObject which would store the counter.
0
 
petmagdyCommented:
but the factory r creational model, which means that the factory will only keep track when creating new objects, what About modifications?

I think u may go for static global last version counter and each object when modified increaments the global version and keeps its own snaphot of its value

at the resolve time the object who has snapshot value of the last global version counter is the last modified
0
 
ycompAuthor Commented:
CEHJ, no I can't really do that though. I mean I do have a factory pattern already that does create the objects. However, it is something like this:


class Machine {
  Settings settings;

}

Widget settings.newWidget()

Widget {
  Settings settings;
}

however Widget objects can be shared among Machine objects. So Widget objects within Machine objects are to be compared to one another for their counter values in order to determine the most recent of each group.

However, since Widget objects can have different settings objects their counter values cannot be compared if the counter resides in settings. Since this would not be a "global" counter.

Since Settings objects can also be shared among Machine objects there is no way for them to point back to a specific Machine object thus the counter cannot be stored in the Machine object.

I guess there is no way to implement a "global" counter without serious re-engineering then... is there no way to get something similar to an ultra-accurate time stamp?
0
 
ycompAuthor Commented:
ah I forgot to say that I am fortunate in that my objects are immutable (well some of them are pooled but the modification time stamp can be set then). The reason I called it a modified stamp instead of a creation stamp is due to the pooling. I guess you might as well just call it a creation stamp.
0
 
ycompAuthor Commented:
anyhow, I might make some of them mutable in the future. But in this case they simply just need to update the value of the counter when the modifications are made.
0
 
ycompAuthor Commented:
sorry forgot to say that my Pool resides within the Settings object.

I see what your saying though, maybe I can liberate the Pool from the Settings object into a global Pool. Cool I guess that will work.
0
 
ycompAuthor Commented:
but if I do this then the Pool either

a) has to be explicitly created by the user of my library or explicitly passed by him to the 2nd Machine object, thereby adding end-user usage complexity. OR;

b) the Pool has to be a static object which I guess would make it accessible to everything running in the VM? So I guess that means it has to be thread-safe right? I mean if I use a static Pool object then this would automatically be the same one in use by all Servlets, right? And I'm guessing that making it thread-safe would seriously impact performance because I'm always using a ton of these widget objects all the time in the code.

by static Pool object I mean something like this:

class Pool {
  public static Pool pool = new Pool();
}
0
 
CEHJCommented:
A pool is of course, normally a single entity (even a singleton). All you need to do is to make the method for obtaining an instance from it synchronized
0
 
ycompAuthor Commented:
so you don't think that would would significantly impact performance if I'm requesting a lot of objects frequently? I mean hundreds of thousands of objects or more in a short period of time? (from each servlet)
0
 
CEHJCommented:
If you're working with servlets and employing pooling, you'll need to make the method to obtain an instance from the pool synchronized anyway, even if you *do* have more than one pool.
0
 
ycompAuthor Commented:
let me use JSP as an example to make it easier to explain:

well the pooling as it stands right now is within the Settings object which is created during each call to the JSP page in order to render the JSP page. So the Pool is created each time the JSP page is called.

It is not like a Resource Pool. The only purpose of this Pool is to reduce object creation and garbage collection.

So I think it doesn't have to be synchronized since the Pool is created and destroyed within a single thread.

Granted though, my knowledge of synchronization is limited. I should read up on it again. But I have bee programming everything under the assumption that there is no need to synchronize when everything is running within a single thread and no non-constant static objects are used.
0
 
objectsCommented:
no need for synchronisation there.

how many objects are typically created during a request?
0
 
ycompAuthor Commented:
well it needs anywhere between say 50 thousand to a few hundred thousand but sometimes can be in the millions. Of course the vast majority are pooled so not too many objects are actually created, maybe max usually 1000 are actually created.
0
 
CEHJCommented:
>>that there is no need to synchronize when everything is running within a single thread

While it's not possible to know exactly whether synchronization is needed without knowing exactly what you're doing (it's less likely if you're only reading), you should know that servlets/JSP are inherently multi-threaded unless they're explicitly created *not* to be.
0
 
CEHJCommented:
8-)
0
All Courses

From novice to tech pro — start learning today.