Be aware of the OS's underlying granularity for time as well: http://docs.oracle.com/javase/6/docs/api/java/lang/System.html#currentTimeMillis%28%29
I almost wonder if it's better to use the RowDeletingIterator in this case. If the check it does is "if TS < delete marker TS", in theory you could get away with putting the delete marker inside the same Mutation as the update and the iterator will mask any data marked with a TS before the delete marker. On Thu, Mar 17, 2016 at 11:18 AM, Josh Elser <josh.el...@gmail.com> wrote: > Server-assigned timestamps aren't noticeably slower than user-assigned > timestamps, if that's what you're referring to WRT throughput. > > As for using currentTimeMillis(), probably fine, but not always. > > 1) NTP updates might cause currentTimeMillis() to change in reverse > 2) You need to make sure the delete and update always come from the same > host (otherwise two hosts might have different values for > currentTimeMillis()) > > Time is hard in distributed systems. > > > z11373 wrote: > >> Thanks Josh! For better throughput, I think I'd just assign the timestamp >> from my code. >> Using this code, System.currentTimeMillis(); for timestamp should be ok, >> right? >> >> >> Thanks, >> Z >> >> >> >> >> -- >> View this message in context: >> http://apache-accumulo.1065345.n5.nabble.com/delete-insert-case-tp16375p16382.html >> Sent from the Developers mailing list archive at Nabble.com. >> >
