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

Tihomir Surdilovic tsurdilo at redhat.com
Fri Sep 9 15:06:57 EDT 2011


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 /<tsurdilo at redhat.com>/* wrote:
>
>
>     From: Tihomir Surdilovic <tsurdilo at redhat.com>
>     Subject: Re: [rules-users] Guvnor repository database use to store
>     assets
>     To: rules-users at lists.jboss.org
>     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 /<tsurdilo at redhat.com>
>>     </mc/compose?to=tsurdilo at redhat.com>/* wrote:
>>
>>
>>         From: Tihomir Surdilovic <tsurdilo at redhat.com>
>>         </mc/compose?to=tsurdilo at redhat.com>
>>         Subject: Re: [rules-users] Guvnor repository database use to
>>         store assets
>>         To: rules-users at lists.jboss.org
>>         </mc/compose?to=rules-users at 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
>>>         /<nicolas.heron.java at gmail.com>/* wrote:
>>>
>>>
>>>             From: Nicolas Héron <nicolas.heron.java at gmail.com>
>>>             Subject: Re: [rules-users] Guvnor repository database
>>>             use to store assets
>>>             To: "Rules Users List" <rules-users at lists.jboss.org>
>>>             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 at lists.jboss.org
>>>             https://lists.jboss.org/mailman/listinfo/rules-users
>>>
>>>
>>>
>>>         _______________________________________________
>>>         rules-users mailing list
>>>         rules-users at lists.jboss.org
>>>         https://lists.jboss.org/mailman/listinfo/rules-users
>>
>>
>>         -----Inline Attachment Follows-----
>>
>>         _______________________________________________
>>         rules-users mailing list
>>         rules-users at lists.jboss.org
>>         https://lists.jboss.org/mailman/listinfo/rules-users
>>
>>
>>
>>     _______________________________________________
>>     rules-users mailing list
>>     rules-users at lists.jboss.org  </mc/compose?to=rules-users at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>     -----Inline Attachment Follows-----
>
>     _______________________________________________
>     rules-users mailing list
>     rules-users at lists.jboss.org
>     </mc/compose?to=rules-users at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20110909/a3a6e86f/attachment.html 


More information about the rules-users mailing list