Hi Frenando, On Mon, Mar 2, 2015 at 7:09 PM, Lemes, Fernando <[email protected]> wrote: > > > Hello guys, > > > > I started to work with Jackrabbit a few months ago and in the project I’m > working we are using Jackrabbit 2.8.0 with MySQL as the persistent manager. > We found some issues regarding the database schema. There are no primary > keys at the journal tables.. is there a reason for that? It seems that in a > MySQL clustered environment this is important for the nodes synchronization.
I'm not sure if there is a specific reason for that. The tables are indeed used for synchronizing the cluster. A lock on the table is used to serialize the updates in the cluster. > Also we have realized that updating the journal GLOBAL_REVISION table > (which is updated all the time) had a performance issue. By examining the > query execution plan we found a temporary table being created. As a > workaround we just added a dummy column with auto increment value as the > primary key, but shouldn’t this table consists only of a column like that? I remember I noticed the temporary table creation as well during some investigation. It has been a while ago but if I remember correctly for our situation it didn't turn out to be a real performance issue. Our situation of course might be wildly different from yours ;-) Do you have any numbers on the performance gain by just adding the dummy auto increment column? Which MySQL storage engine are you using? If the revision id column would be an auto incremented value it would mean the "ownership" of the revision number (generation) would be transferred from Jackrabbit to the database. That could impact the portability of the code to other backends or the flexibility in Jackrabbit for handling the revision ids. I'm not sure if that would be a real issue. However changing the storage format in MySQL would have an impact for existing installations and require a migration of the schema when upgrading. > We have also implemented a feature to remove Jackrabbit dead nodes from > the LOCAL_REVISION table, so the janitor can work properly even in a > scenario where cluster nodes may be destroyed anytime. How can I submit this > patch? Could you explain how your solution works? How do you decide if a node is just shutdown for a while or "dead"? Regards, Bart > > > > > > Regards, > > > > Fernando Lemes da Silva > > Software Designer – Brazil R&D > > [email protected] > > +55-11-4197-8124 > >
