Re: [rules-users] Guvnor repository database use to store assets

Initially, we had Guvnor deployed to only one instance of weblogic and using the database to store workspace, repository and versioning information in the database . This configuration was generated using the Manage Repository configuration option in Guvnor later, Guvnor was mistakenly deployed to more than one instance of weblogic in a cluster , but each of the Guvnor using the same database through jndi datasource. The repository.xml remained the same without any clustering setup. Now, we see that each Guvnor instance has created a cluster_node.id file and also a revision.log file on the local file system. could the multiple instances of Guvnor created a need for jackrabbit to recreate/update the Table ?

we see that this Table FS_WS_DEFAULT_FSENTRY seems to have been recreated /updated after the permissions for the Guvnor database user was changed back to db_owner from db_datareader and db_datawriter. Could the multiple instances of Guvnor one each in a weblogic cluster setup have required changes to the Table structure ? As always,Thank you for your feedback . --- On *Fri, 9/9/11, Tihomir Surdilovic /&lt;tsurdilo(a)redhat.com&gt;/* wrote: From: Tihomir Surdilovic <tsurdilo(a)redhat.com&gt; Subject: Re: [rules-users] Guvnor repository database use to store assets To: rules-users(a)lists.jboss.org Date: Friday, September 9, 2011, 12:06 PM If you choose to store your repository in an external db, then you should do it in all places of your repository.xml. Mixing the file system with external db in repository.xml is not recommended. Regarding: >> we have another Guvnor which uses the following setting for workspace.This seems to be working without any issues when we delete the workspace and repository directory and deploying Guvnor again. it is likely that this setting does not store workspace information in the database and hence does not need to create additional tables? On 9/9/11 1:07 PM, puja nandamuri wrote: << Well of course, If you use the LocalFileSystem, you are not using your external database. The root of your initial problem was as you mentioned: >> The DBA had locked the userid permissions to prevent any new table creation in the Guvnor database. << Also mentioned previously was that Jackrabbit will create the tables in an external db only the first time, so any consequent start will not as the tables already exist. Also was mentioned that Jackrabbit will still try to query the table metadata, and for you to make sure the db user you specify in your DroolsRepositoryDatasource config has the permissions to do that. I would look on your end for couple of things: 1) What repository.xml file is being accessed by Guvnor when you deploy a new war? Is it really the one you think it should? 2) Check with your DBA so he can play with permissions to see what is the least amount of permissions he can give your db user in order for this to work. 3) Check if this could be related to you importing a repository xml file after re-deployment. AFAIK this operation should not create any new tables, but you could check. Since Jackrabbit has it's own db schema, I do not really see a need to "lock down" permissions of the user. Not sure why this is necessary on your end tobegin with. Could you explain? Thanks. > I got some additional details on the issue. i would appreciate > some advice on whether I should be storing the workspace to a > local file system or database . > > In my repository.xml, I have the following setting for the > workspace file system. > > <Workspace name="${wsp.name}"> > > <!-- > > virtual file system of the workspace: > > class: FQN of class implementing the FileSystem interface > > --> > > <FileSystem class="org.apache.jackrabbit.core.fs.db.MSSqlFileSystem"> > > <param name="driver" value="javax.naming.InitialContext"/> > > <param name="url" value="droolsRepositoryDataSource"/> > > <param name="schema" value="mssql"/> > > <param name="schemaObjectPrefix" value="FS_WS_${wsp.name}_"/> > > </FileSystem> > > > Is it likely that because Guvnor seems to be storing the > workspace information in the database , it is trying to create > the database tables again for workspace during guvnor restart > after deleting workspace and repository directories on file system? > > > > > we have another Guvnor which uses the following setting for > workspace.This seems to be working without any issues when we > delete the workspace and repository directory and deploying > Guvnor again. it is likely that this setting does not store > workspace information in the database and hence does not need to > create additional tables? > > > <FileSystem > class="org.apache.jackrabbit.core.fs.local.LocalFileSystem"> > > <param name="path" value="${wsp.home}"/> > > </FileSystem> > > > > > --- On *Tue, 9/6/11, Tihomir Surdilovic /&lt;tsurdilo(a)redhat.com&gt; > </mc/compose?to=tsurdilo(a)redhat.com&gt;/* wrote: > > > From: Tihomir Surdilovic <tsurdilo(a)redhat.com&gt; > </mc/compose?to=tsurdilo(a)redhat.com&gt; > Subject: Re: [rules-users] Guvnor repository database use to > store assets > To: rules-users(a)lists.jboss.org > </mc/compose?to=rules-users(a)lists.jboss.org&gt; > Date: Tuesday, September 6, 2011, 9:33 AM > > All Jackrabbit template ddl files are in the jackrabbit-core > jar. That would be a good place to start. > > Thanks. > On 9/6/11 12:18 PM, puja nandamuri wrote: >> the account configured for the repository database has the >> following change of permissions after the intial tables >> creation by Guvnor. >> >> changed db_owner to db_datareader,db_datawriter and as >> usual, it has public rights. >> >> I am not an database expert but, should not the above >> permissions allow for ( DatabaseMetaData#getTables) ? >> >> any pointers on what exactly might be the sql used in this >> case ? >> >> Thanks, >> >> Ram >> >> --- On *Mon, 9/5/11, Tihomir Surdilovic >> /&lt;tsurdilo(a)redhat.com&gt;/* wrote: >> >> >> From: Tihomir Surdilovic <tsurdilo(a)redhat.com&gt; >> Subject: Re: [rules-users] Guvnor repository database >> use to store assets >> To: rules-users(a)lists.jboss.org >> Date: Monday, September 5, 2011, 11:02 AM >> >> Jackrabbit will not try to create any new tables after >> it initially created them. However it does call a >> *PersistenceManager.checkSchema() method which AFAIK >> tries to read from the db metadata ( >> DatabaseMetaData#getTables). If the user does not have >> permissions to do that, it will fail which I think is >> the case in your scenario. >> >> Thanks. >> On 9/5/11 1:04 PM, puja nandamuri wrote: >>> Hi, >>> >>> Sorry, I think the original question I had asked still >>> seems to have been unanswered. >>> >>> This is the question I had. >>> >>> does Guvnor keep creating additional tables as per the >>> need or is the Table structure that Guvnor creates in >>> the beginning where all the assets are stored remains >>> the same until we manually delete the Tables? >>> >>> >>> after creating rules and assets for several days, we >>> had to re deploy a freshly compiled Guvnor war file( >>> everything remaining the same) using the same >>> repository xml and same database connected through jndi >>> datasource. >>> >>> In other words, just the war file has been recompiled. >>> we also deleted the workspace and repository >>> directories previously created by Guvnor. >>> >>> The DBA had locked the userid permissions to prevent >>> any new table creation in the Guvnor database. >>> >>> During Guvnor startup, Guvnor had complained about not >>> having permission to create Tables. >>> >>> My question is : >>> >>> why does Guvnor need to create any additional tables >>> and not use the existing Table structure in the database. >>> >>> I would appreciate any thoughts on this. >>> >>> >>> >>> >>> >>> --- On *Sun, 9/4/11, Nicolas Héron >>> /&lt;nicolas.heron.java(a)gmail.com&gt;/* wrote: >>> >>> >>> From: Nicolas Héron <nicolas.heron.java(a)gmail.com&gt; >>> Subject: Re: [rules-users] Guvnor repository >>> database use to store assets >>> To: "Rules Users List" <rules-users(a)lists.jboss.org&gt; >>> Date: Sunday, September 4, 2011, 10:52 PM >>> >>> Hi, >>> >>> Sorry, but you do not have to delete the >>> workspace directory. Not sure where you are >>> getting this from? In cases where you have a >>> large number of packages/assets in Guvnor it is >>> rather recommended _not_ to delete the search >>> indexes written onto the file system, because >>> it takes extra time to re-create them. >>> >>> May be it is recommended. But when you modify a lot >>> the assets, rename, copy, delete,etc.. Guvnor gets >>> lost. >>> >>>> At startup, Jackrabbit (containent in Guvnor) >>>> reads all the database and creates the two >>>> directories. You do not need to backup them. >>> Again, I don't know where you are getting this >>> from. Jackrabbit does _not_ read the entire DB >>> on startup and does not write any of the JCR >>> content stored in an RDBMS to the file system >>> if you have configured it to store to the >>> RDBMS. If you for any weird reason are seeing >>> this on your end, you should really have >>> another look at your repository.xml. >>> >>> >>> >>> The search indexes, they are stored on the file >>> system no ? And with no index, you cannot reach any >>> of the assets. So when you delete thoses >>> directories, at startup, they are re-created and >>> the database is read. I do not know what is read, >>> but it can take quite some times, depending on the >>> size of the package. Now If there is a way to store >>> thoses indexes in the database, I would be happy to >>> know how. >>> >>> The project I am on has many rules and many big web >>> decision tables that end up with more than 100000 >>> rules. I am using 5.3 snapshot with MVEL beta6 => >>> Startup time =5 minutes and building the package, 3 >>> to 5 minutes on a HP G6 processor. On my PC that >>> has an i5 processor and a 32 bits linux, I cannot >>> build anymore the package. >>> With those sizes, which is not that much, >>> Guvnor/jackrabbits gets lots on the indexes : it >>> gives jackrabbit exceptioorn or spaces are not >>> considered. So then, what I do is delete those two >>> directories and restart guvnor and everything is >>> fine again. >>> Thanks >>> Nicolas >>> >>> >>> >>> -----Inline Attachment Follows----- >>> >>> _______________________________________________ >>> rules-users mailing list >>> rules-users(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/rules-users >>> >>> >>> >>> _______________________________________________ >>> rules-users mailing list >>> rules-users(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/rules-users >> >> >> -----Inline Attachment Follows----- >> >> _______________________________________________ >> rules-users mailing list >> rules-users(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users >> >> >> >> _______________________________________________ >> rules-users mailing list >> rules-users(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users > > > -----Inline Attachment Follows----- > > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > > > > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org </mc/compose?to=rules-users(a)lists.jboss.org&gt; > https://lists.jboss.org/mailman/listinfo/rules-users -----Inline Attachment Follows----- _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org </mc/compose?to=rules-users(a)lists.jboss.org&gt; https://lists.jboss.org/mailman/listinfo/rules-users _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users