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>
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: 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
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20110909/63344a9d/attachment.html