Obtaining the Timestamp of my last insert/update

[Bob Schulze <b....@ecircle.com>]

Unfortunately,  a BatchUpdate object does not get this field updated
upon Htable.commit(), if  it was left unset (it remains set to its
default LATEST_TIMESTAMP, on 0.19.1).

Could that be done? This would allow some use cases that otherwise have
to be implemented using a RowLock.

Thx,

	Bob

Re: Obtaining the Timestamp of my last insert/update

[Bob Schulze <b....@ecircle.com>]

Erik Holstad schrieb:
> Hi Bob!
> What would be the use case where you could use an explicit timestamp instead
> of using the rowlock?
> To me they are used for different things, so what are you planning to to
> with them?
> 

I have a use case, where a big batch of personalized documents are
created in a short time (simultaneously on may computers, to be stored
then). Instead of keeping all docs in full, I want to store the diff of
them only.

For this, whenever a doc apprears the first time, I store it in a
"master" table. The next store op will then look it up, calculates a
diff and keeps it in a "doc" table, together with a the reference to the
master doc.

As many clients may want to store a master (for the same doc) in a small
time period, I use a reference in the form <rowkey.timestamp>. The
disadvantage is having a non optimal compression (I may have more than
one master copy). But I do not have to lock anything anymore.

(It reminds me also on use cases for MySQL's get_last_insert_id()
method...)

So the return of the Timestamp would help. It means that the Timestamp
should be assigned already early in the update code; I think today it is
not (only in a flush operation later).

Right now I use the client side timestamp (millies), but got already
collisions.


Bob

Re: Obtaining the Timestamp of my last insert/update

[stack <st...@duboce.net>]

On Mon, May 25, 2009 at 10:20 PM, Ryan Rawson <ry...@gmail.com> wrote:
>
> A more philosophical question for the other devs, should we consider
> depreciating the use of the explicit row lock... lock acquisition is slow
> and dangerous, since it can DOS the server.  Or perhaps change the semantics
> to have a low-lock-wait period (lets say 20-50ms?), so the client can
> busy-wait the server instead of tying up IPC threads?

Yes. We need this.  Should we do this as part of 0.20.0 when we're
doing all the other API?  Change the lock call adding a timeout or
just stipulate internally how long it waits returning success or
timeout dependent on whether lock was acquired or not?

St.Ack

Re: Obtaining the Timestamp of my last insert/update

[Ryan Rawson <ry...@gmail.com>]

For this case, I am with Erik, use an explicit timestamp, what does it
matter if the timestamp is set on the client or server side, milliseconds
apart?

A more philosophical question for the other devs, should we consider
depreciating the use of the explicit row lock... lock acquisition is slow
and dangerous, since it can DOS the server.  Or perhaps change the semantics
to have a low-lock-wait period (lets say 20-50ms?), so the client can
busy-wait the server instead of tying up IPC threads?





On Mon, May 25, 2009 at 10:04 PM, Erik Holstad <er...@gmail.com>wrote:

> Hi Bob!
> What would be the use case where you could use an explicit timestamp
> instead
> of using the rowlock?
> To me they are used for different things, so what are you planning to to
> with them?
>
> Regards Erik
>

Re: Obtaining the Timestamp of my last insert/update

[Erik Holstad <er...@gmail.com>]

Hi Bob!
What would be the use case where you could use an explicit timestamp instead
of using the rowlock?
To me they are used for different things, so what are you planning to to
with them?

Regards Erik

Re: Obtaining the Timestamp of my last insert/update

[stack <st...@duboce.net>]

There is HBASE-1014 filed against 0.20.0.  I do not know what its
state is, if it'll make it in or not.
St.Ack

On Mon, May 25, 2009 at 7:43 AM, Bob Schulze <b....@ecircle.com> wrote:
> Unfortunately,  a BatchUpdate object does not get this field updated
> upon Htable.commit(), if  it was left unset (it remains set to its
> default LATEST_TIMESTAMP, on 0.19.1).
>
> Could that be done? This would allow some use cases that otherwise have
> to be implemented using a RowLock.
>
> Thx,
>
>        Bob
>