Resuming an interesting conversation about current Fenix developments.

[sledorze]

Sorry to start so quickly:

[..Talking about resumable transactions and the fact that a
multiversioned DB would help with that..]
> Yes but there's still some possibility to have too much connections;
> so I wonder when your multi versionned DB would be available (and
> remove this possible failure).

We have already an HBase-based implementation that has all the
versions,
but I don't consider it production ready. For several reasons:

- I'm not sure that HBase itself is production-ready
- It does not support multiple servers because the distribution
aspects are not merged into this implementation

Meanwhile, we are progressing towards adding the multiple versions to
the MySQL backend, but that is moving slowly. I doubt it that it will
be ready before the end of August.

Nevertheless, once we have the suspend/resume of transactions, the
current version of the fenix-framework has a bound on the maximum
number
of open connections to the database, which is equal to the number of
servers accessing the DB times the maximum number of connections
allowed
per server. Currently, I believe that this per-server value is 61 by
default, but, typically, according to our logs, each server uses less
than 10 DB connections.

If you have more requests to a server than available DB connections,
then the requests will wait for the availability of a connection. So,
provided that you have the DB and the servers consistently configured,
you should not get any error with the current solution.

In summary, I believe that, even though it may need to be tuned, the
current approach will not be a problem. At least, I believe it to be
much better than what it would be if you were using a "traditional"
approach to access the DB.


Regarding the change from one box per-slot to one box per-object:

> What would it change for us? (we're currently using introspection for our tools)
> for instance what the "getSlotsList" method of DomainObject would return?
> (I am confortable adapting but knowing earlier is better)

I suppose that you're talking about the getSlotsList method from the
dml.DomainClass class, right?

That method will continue to return the same thing as it is now. The
DomainModel will not change. What changes is the code that is
generated
from it.

Still, even in that case, the API generated will be the same. Only
its
implementation will be different.

So, unless you are accessing directly via reflection the slots of the
Base classes, which currently are one VBox for each slot, you should
not
have to change anything. What are you doing with the value of the
getSlotsList method?


> What benefice comes with this new way of implementing relations?

He is implementing a BTree on top of the fenix-framework and will use
this persistent BTree to represent collections.

This will allow the implementation of ordered and indexed relations,
as
well as accessing normal relations without having to load all of the
elements in a collection at once. So, unless you need to traverse the
entire collection (in which case you will have to load all objects
either way), this will allow accessing very large collections without
the cost of loading them all, as currently happens.


> About ordered and index relations; it is something that has been seen
> as needed and currently problematic (generates a lot of intermediate
> objects on our side to encode the order); do you think it could be
> available soon?

I expect so. I don't know for sure, but I would expect to have a
tested
version in the two following weeks. Actually, if these messages were
being exchanged via the Google group, they might serve as incentive
for
him to finish things earlier ;)

> Understand and agree; nevertheless your indexed feature would be very
> helpful; how would we specify it in the DML?

Actually, that was something that was planned for a long time ago, and
there was already some partial syntactic support for it in the DML.
You
can see some examples on this paper:

http://doi.acm.org/10.1145/1145581.1145640


Best regards,
--
João Cachopo

[Damián]

> > About ordered and index relations; it is something that has been seen
> > as needed and currently problematic (generates a lot of intermediate
> > objects on our side to encode the order); do you think it could be
> > available soon?
>
> I expect so.  I don't know for sure, but I would expect to have a
> tested
> version in the two following weeks.  Actually, if these messages were
> being exchanged via the Google group, they might serve as incentive
> for
> him to finish things earlier ;)

Any news on this?


Damián

[Joao Cachopo]

Damián <damian....@gmail.com> writes:

Sérgio Silva may tell you better but I think that it is almost done.

Still, as adding this new way of storing relations causes some major
changes in how things are stored in the database, Sérgio will commit his
changes to a branch rather than to the main trunk. This way we will
more time to test it and iron out any problems before promoting it to
the main trunk.

[Stephane Le Dorze]

Hi! Do you know where I could find this document without ACM access?

 http://doi.acm.org/10.1145/1145581.1145640

I googled a bit with what I've saw in the title and the abstract without any luck..

I think it would be nice to give free access to such documents to promote the Fenix Framework; otherwise I will have to register..

Stephane