Hi Mike, 

 

All right, I’ll start doing my ‘homework’ in order to get myself
familiarized with the Geode codebase.

 

At present I do not wish to learn your ideas as this may cloud my own
creative thinking process. So we’ll discuss later on that.

 

Are you having any concrete timelines on this project right now ?

 

Also I’d like to learn your views on my last question, which I will
elaborate a bit more.

 

Suppose two transactions (A, B) are executed on two different nodes which
have a deviation in system time. Also there is a third process (R) which
reads data that is affected by both transactions (which will also ‘commit’
it’s reads in order to be sure to read a consistent state). 

 

In real time the execution order is A à R à B, but due to system time
deviation the order of transactions is logged the other way around. As a
consequence one can’t reconstruct the read state of R. The only way around
it, which I can think of given my limited knowledge on distributed
transaction, is to take a global lock (which is not an option in my
opinion). 

 

Can anyone think a better solution than keeping system times as close as
possible together and accepting that there may happen conditions which cause
that you can’t construct the read state of R?

 

Maarten,

 

I would be interested in spending some cycles thinking through how to best

implement bi-temporality in Geode. I have implemented bi-temporality using

several traditional databases, and I have some ideas how to implement both

time-series and bi-temporal data in Geode, but it would be interesting to

have someone who really knows the subject matter well to work with.

 

--

Mike Stolz

Principal Engineer, GemFire Product Manager

Mobile: 631-835-4771

 

On Sun, May 15, 2016 at 6:18 PM, Maarten Niederer <
<mailto:[email protected]> [email protected]>

wrote:

 

Hi guys,

 

I'm considering to contribute to the Geode project. My attention is drawn

because of the desire to create a bi temporal framework in a distributed

database system. This should provide me nice engineering challenges.

 

At my present employer I have worked with and developed an application that

implements a bi temporal framework within the application layer build on

top

of an old school RDBMS. I have done a lot development with temporal logic

(value time). For example, I've implemented several  SQL operations (e.g.

outer joins, group/aggregate) in a temporal way (e.g. find me the intervals

in time when more developers than managers worked at company X given the

temporal data on when people started/stopped working and their

professions).

Also I've been busy with implementing the procedure that writes the change

log for these temporal tables which allows to inspect these tables at any

transaction time. During this work I found several shortcomings to

implementing these features within the application layer, which could be

only resolved if there's proper support in the RDBMS instead.

 

So I know a lot about bi temporal data, I know only a bit on distributed

transactions (I learned some in university and the clubhouse presentation

by

Swapnil was excellent for knowledge transfer). Finally I don't know

anything

about the Geode code base. So my first action would be to tackle starter

JIRAs for half a year or so in order to get some familiarity with the

codebase.

 

However before I start to blow a big shot of my personal time, I'd like to

know whether there are several people who like to support implementing the

bi temporal framework. As it requires thorough review both on design and

code (and preferably even test coverage). Also for the work on the

transaction time dimension, the current work being done on the transactions

should be completed. Also we will probably need a fundamental discussion on

'transaction time' and corresponding 'read consistency' in a distributed

context.  (Is there always some snapshot which matches exactly what a

client

observed at some point in time?).

 

Also good for you to know, most of my time I reside in the CET timezone.

 

Best regards,

 

Maarten Niederer

 

Reply via email to