BocaConfiguration
From IBM Semantic Layered Research Platform
←Older revision | Newer revision→
In this section we delve into the nitty-gritty of teaching Boca configuration. We split our discussion into three sections. First, we provide examples of the various Boca client and server configuration properties configuration files and explain the scenarios in which they are used. We also include an exhaustive list of configuration properties and their different uses. The second section discusses the RDF documents used to initialize and reset the database. The final section explains a few DB2 database configuration considerations.
Contents |
Boca configuration properties and property files
Boca configuration property files are difficult to understand because the same property can have a different meaning in two different files. The example configuration files work quite well, and we recommend that new Boca users use the example configurations to get started. If you'd like to customize your Boca configuration, please use this page as a guide: We endeavor to take you through an example of each configuration scenario as well as provide a complete description of all properties for reference.
Scenario 1: The Boca server configuration
This file is typically named BocaServer.properties.db2 in the binary distribution and BocaServer.properties in the source distribution's Eclipse project, com.ibm.adtech.boca.standalone. In general, it is advisable to modify one of these two, but an admin may use a different properties filename. In this case it must be specified on the command line as follows:
java com.ibm.adtech.boca.standalone.BocaServer -p <propertyfile>
We now go through the example of the properties file included in the binary and source distributions of the Boca server. For starters, this example should work with only slight modification, but it may need more significant modification as the user's needs evolve. In particular, many of the properties in the server configuration are used by server components to talk to one another. When running the Boca standalone server, these defaults should be left in place since it is this particular wiring that defines the standalone server. Only when server components are broken out and distributed across a network do these properties require modification.
com.ibm.boca.repository.database.driver = com.ibm.db2.jcc.DB2Driver com.ibm.boca.repository.database.user = db2inst1 com.ibm.boca.repository.database.password = db21nst! com.ibm.boca.repository.database.url = jdbc:db2://localhost:50000/boca com.ibm.boca.repository.database.clear = false com.ibm.boca.repository.database.type = BocaDB2
This first set of properties define how the Boca server connects to the DB2 database, and will probably require modification based on the particular DB2 choices made during DB2Setup. Boca works exclusively with the new IBM JCC JDBC driver. Most Boca servers will connect to a local database on port 50000 (the install default), and boca is as good a name as any for a Boca database. The clear property indicates whether or not the database should be cleared on startup each time. Typically, this should be false.
com.ibm.boca.repository.webserver.port = 8080 com.ibm.boca.repository.webserver.timeout = 360000
These next two properties determine the port on which the Web Service endpoint of the server should listen, as well the timeout for stale connections (in milliseconds).
com.ibm.boca.repository.initFile = resource:/com/ibm/adtech/boca/model/initializeNew.nt com.ibm.boca.repository.reset.enabled = true com.ibm.boca.repository.authenticationProvider = com.ibm.adtech.boca.model.security.BocaAuthenticationProvider
These three properties pertain to behavior of the Boca repository. The initFile property specifies an RDF document used to initialize user, named graphs and access controls when the server starts for the first time. We detail this file in a later section in this article. In BocaProgrammingModel we discussed the reset operation. The reset.enabled property determines if this operation is enabled. In production environments, reset ought to be disabled. Finally, the authenticationProvider defines a class that handles authentication of users. BocaSecurity details this extensibility point.
Configuring the notification systems
com.ibm.boca.repository.notification.broker.enabled = true com.ibm.boca.repository.notification.broker.host = vm://localhost com.ibm.boca.repository.notification.broker.port = 61616
In most cases, modification of the notification configuration is unnecessary. As described in BocaArchitecture, the standalone server runs its own JMS broker. These first properties configure it. enabled determines whether or not the JMS broker is started at all. The other two properties specify host (network adapater) and port to listen on.
com.ibm.boca.repository.notification.publisher.enabled = true com.ibm.boca.repository.notification.publisher.host = vm://localhost com.ibm.boca.repository.notification.publisher.port = 61616 com.ibm.boca.repository.notification.publisher.jmsProviderClass = com.ibm.adtech.boca.jms.ActiveMqProvider com.ibm.boca.repository.notification.publisher.user = sysadmin com.ibm.boca.repository.notification.publisher.password = 123
The details of the notification service are described in BocaNotification. But in general, the notification service refers to a set of distributed server components that publish named graph and other updates to the JMS cloud, as well as the central multiplexing queue that receives updates from the cloud and publishes them back into the cloud bound for particular users who have permission to see them and who are interested in them. All publishing components of the notification service use the repository.notification.publisher family of properties.
The notification service that publishes updates as transactions are committed to the database as well as the multiplexing queue component use the above properties to connect to the JMS broker. In other words, two server components are using the same set of properties. In standalone mode, this makes perfect sense as they are running on the same machine.
com.ibm.boca.modelService.transportClass = com.ibm.adtech.boca.model.embedded.EmbeddedModelService com.ibm.boca.modelService.user = sysadmin com.ibm.boca.modelService.password = 123
The multiplexing message queue component of the notification service uses an embedded client model service to check which update messages need to be forwarded to which users, based on permissions and subscriptions since all of this information is stored in the Boca database itself.
com.ibm.boca.notification.user = sysadmin com.ibm.boca.notification.password = 123 com.ibm.boca.notification.host = tcp://localhost com.ibm.boca.notification.port = 61616 com.ibm.boca.notification.jmsProviderClass = com.ibm.adtech.boca.jms.ActiveMqProvider
The multiplexing message queue component of the notification service also connects to JMS as a client to receive updates to objects it caches from the embedded model service. It uses the above properties to connect to JMS. These are separate from previous repository.notification properties because receiving updates to cached objects is more of a client operation. In standalone, however, the values happen to be the same, and should require no modification.
Scenario 2: The Boca Web Service client configuration
The Boca Web Service client configuration is more straightforward, as the client really only wears a single hat: that of a client connecting to services, combined with a few local configuration details.
com.ibm.boca.notification.host = localhost com.ibm.boca.notification.port = 61616 com.ibm.boca.notification.jmsProviderClass = com.ibm.adtech.boca.jms.ActiveMqProvider com.ibm.boca.notification.enabled = false com.ibm.boca.notification.user = default com.ibm.boca.notification.password = 123
Here we connect the client to the JMS broker in a standard way. Authentication to the JMS broker assures that users only get the triples they are tracking and have permission to read. If a Boca client application will be gathering a user name and password from the end user, then those values can be set programmatically via a java.util.Properties object. Notice that the enabled property is set to false. In the examples covered in BocaProgrammingModel, we enable notification explicitly in the code, overriding the configuration parameter. Either approach is fine, we just happened to implement it that way.
com.ibm.boca.modelService.host = localhost com.ibm.boca.modelService.port = 8080 com.ibm.boca.modelService.user = default com.ibm.boca.modelService.password = 123 com.ibm.boca.modelService.timeout = 0
Here we specify the connection to the Boca Web Service endpoint. A timeout value of 0 indicates that the connection never times out.
com.ibm.boca.replication.timeout = 0
There are other replication settings available, but in this example we only set the timeout for the replication service below. Other settings will be covered in the exhaustive list below.
com.ibm.boca.local.persistence.enabled = false com.ibm.boca.client.database.fileLocation = /tmp/boca-database com.ibm.boca.client.database.modelName = testModel com.ibm.boca.client.database.clear = true
This section covers local persistence. Because enabled is set to false, the remainder of the client database properties are ignored. However, were it be enabled, an Apache Derby database would be created at the given file location, and it would be cleared each time the client starts up. This last option (clear) is good for debugging, but should of course be turned off when the application is run in a production environment. For more details on client persistence, see BocaLocalPersistence.
Scenario 3: The Boca embedded client configuration
We briefly discussed the Boca embedded mode client in BocaProgrammingModel and more in depth in BocaArchitecture. In short, the embedded client provides a way to connect directly to the Boca backend database through Java, without the Web Service layer in between. This allows for applications running on the same machine as the database to take advantage of that locality. The canonical use case for the embedded client is a Web application. Configuration of the embedded client is a bit tricky because we require elements from both the client and server configuration. Another thing to keep in mind is that even though the embedded configuration specifies connections to a JMS broker, it does not run such a broker itself. BocaArchitecture explains this further.
com.ibm.boca.modelService.transportClass = com.ibm.adtech.boca.model.embedded.EmbeddedModelService com.ibm.boca.replication.replicationClass = com.ibm.adtech.boca.model.embedded.EmbeddedReplicationService com.ibm.boca.notification.notificationClass = com.ibm.adtech.boca.model.embedded.EmbeddedNotificationService
The transportClass specifies an embedded connection to the Boca database without the Web Service. Embedded mode also specifies its own replicationClass. In embedded mode, the concept of replication is not quite as clear. However, it is necessary to replicate committed transaction in the queue to the database. This enables multiple embedded mode clients to use the same Boca database. The embedded client does not maintain local models through notification, the notificationClass is just a place holder but must be specified nevertheless.
com.ibm.boca.modelService.user = default com.ibm.boca.modelService.password = 123 com.ibm.boca.modelService.defaultAclUri = http://boca.adtech.internet.ibm.com/ACL/1 com.ibm.boca.modelService.defaultRoleUri = http://boca.adtech.internet.ibm.com/Role/default
The user and password are used by the embedded client to connect to the Boca backend. In the case of Web applications, this will usually be some trusted system user. BocaSecurity describes the ability to run as individual users to authenticate particular requests. The default ACL and role are applied to every named graph as it is created. These are defined in the initialization file specified below, however we give these as an example.
com.ibm.boca.replication.timeout = 0
This is the timeout for replicating with the database. In the embedded setting, there is no network connection other than to the database so timeout should not be an issue. A value of -1 indicates no timeout.
com.ibm.boca.local.persistence.enabled = false
Even though the local model triples in embedded mode may be maintained in a persistent store, it doesn't make sense to do so since the database itself is local.
com.ibm.boca.repository.database.driver = com.ibm.db2.jcc.DB2Driver com.ibm.boca.repository.database.user = db2inst1 com.ibm.boca.repository.database.password = db21nst! com.ibm.boca.repository.database.url = jdbc:db2://localhost:50000/boca com.ibm.boca.repository.database.type = BocaDB2
Here we specify the connection to the database, just as we did in Scenario 1.
com.ibm.boca.repository.initFile = resource:/com/ibm/adtech/boca/model/initializeNew.nt
The initFile property specifies a Java resource containing an RDF document of initial named graphs, users, roles and ACLs. The format of these files is described in detail below but the files are fairly readable themselves. Basically, each named graph has a single acl. An acl is simply a list of role-permission pairs. A role is a list of users or other roles. For example, ng1 might have acl1 that has role1-read and role1-write. role1 might contain user1 and user2. The defaultSystemGraph is a reserved, virtual named graph whose permissions affect who can add and remove named graphs from the system.
com.ibm.boca.repository.reuseConnections = true com.ibm.boca.repository.cacheStatements = false com.ibm.boca.repository.reset.enabled = true
Only the reset.enabled property requires modification here. In a production environment, this ability should be turned off as it is not an authenticated operation. That is, if reset is enabled, any user can invoke it.
We conclude with the notification configuration of the embedded client. The embedded client has two notification components. The first (SUB) is a notification service client that receives updates to named graphs and triples to which it is subscribed. However, the triples do not come in via the local and remove models since these are connected to the database itself. Instead, we provide an API for registering custom notification listeners. We will provide an example of this in a later article. The second component (PUB) operates without any intervention or custom code. This is a notification service component that publishes updates of all named graphs into the cloud.
As a use case for these two notification components, consider a Web application that uses the embedded client. The Web application may run on multiple Web servers that are all connected to the same backend database. However, the application may cache certain responses or named graphs for performance purposes. The notification system can be used to invalidate these caches when a named graph is touched by the Web app on another app server. For example, suppose we are using Boca as a backend for a Semantic Wiki system. An end user loads a wiki page and the browser makes an HTTP request to the Web app on Web Server A that in turn makes a request for the named graph via the Boca embedded client. The web app caches the wiki page in the main memory of Web Server A, just in case the page is requested again. Now, suppose that another user makes a change to the wiki page via an HTTP Put on Web Server B. Web Server B updates the Boca database. However, how is Web Server A supposed to know to invalidate the cached wiki page? It works as follows. When B updates the wiki page, the embedded client publishes the committed transactions using the PUB notification component. A receives the update and invalidates the cache, using a custom listener registered using the API of the SUB notification component.
com.ibm.boca.notification.host = localhost com.ibm.boca.notification.port = 61616 com.ibm.boca.notification.jmsProviderClass = com.ibm.adtech.boca.jms.ActiveMqProvider com.ibm.boca.notification.enabled = false com.ibm.boca.notification.user = sysadmin com.ibm.boca.notification.password = 123
We begin with the notification client properties (SUB). Here notification is disabled and should be enabled in order to receive updates. The rest are standard notification properties.
com.ibm.boca.repository.notification.publisher.host = localhost com.ibm.boca.repository.notification.publisher.port = 61616 com.ibm.boca.repository.notification.publisher.jmsProviderClass = com.ibm.adtech.boca.jms.ActiveMqProvider com.ibm.boca.repository.notification.publisher.user = sysadmin com.ibm.boca.repository.notification.publisher.password = 123
Here, the notification service (PUB) properties are the same as the client properties as they will be in most cases.
com.ibm.boca.repository.notification.publisher.enabled = false
Finally, if we are running only one embedded client without the need for publishing and subscribing to events, we can disable update publishing with the above property. We use this in the embedded client samples of BocaProgrammingModel.
Boca configuration property reference
We now include an exhaustive listing of all properties that the Boca user or administrator is likely to encounter. This list will grow as we reveal more configuration points in the system. To begin with, this list is based mainly off the three configuration scenarios. In fact, for each property, we describe the part, if any, it plays in each of the three configuration scenarios. This list contains a few properties not described in the example scenarios above, but that still fit in to one or more of them. The description section of the table is split into Client, Server, and Embeded mode scenarios. If two scenarios have the same description, the corresponding letter is included in italics. If a particular property is not used in a given scenario we denote that with na. The examples provided are in most cases the default value. Some properties such as usernames and passwords do not have default values. In some cases, an example pertains to a particular scenario and is duely noted.
Model service client properties
| property | description | example |
|---|---|---|
| com.ibm.boca.modelService.transportClass | C: Transport for model service calls. S: na E: Defines embedded mode | com.ibm.adtech.boca.services.impl.WSModelService(C) com.ibm.adtech.boca.model.embedded.EmbeddedModelService(E) |
| com.ibm.boca.modelService.host | C: The hostname of the Boca Web service to connect to. S: The hostname of the model Web service that backend server components make use of. E: na | localhost |
| com.ibm.boca.modelService.port | C: The port of the Boca Web service to connect to. S: The port of the model Web service that backend server components make use of. E: na | 8080 |
| com.ibm.boca.modelService.user | C: The username for connecting to the Boca server S: The username for connecting to the model service that backend server components make use of. E: The username to run commands against the embedded model service | default |
| com.ibm.boca.modelService.password | C: The password for connecting to the Boca server S: The password for connecting to the model service that backend server components make use of. E: The password to run commands against the embedded model service | 123 |
| com.ibm.boca.modelService.defaultAclUri | C: The default ACL applied to named graphs as they are created S: na E: C | http://boca.adtech.internet.ibm.com/ACL/1 |
| com.ibm.boca.modelService.defaultRoleUri | C: The default Role applied to users S: na E: C | http://boca.adtech.internet.ibm.com/Role/default |
| com.ibm.boca.modelService.timeout | C: The timeout for Web Service calls to the model service S: The timeout for Web Service calls to the model service by server components E: na | 0 |
Replication properties
| property | description | example |
|---|---|---|
| com.ibm.boca.replication.replicationClass | C: Replication implementation for DatasetService. S: na E: Defines embedded mode | com.ibm.adtech.boca.services.impl.WSReplicationService(C) com.ibm.adtech.boca.model.embedded.EmbeddedReplicationService(E) |
| com.ibm.boca.replication.timeout | C: The timeout for calls to the replication service S: The timeout for calls to the replication service by server components E: C | 0 |
| com.ibm.boca.replication.mode | C: How and when replication is initiated S: na E: C | 1 == IMMEDIATE Replication started asynchronously (non blocking, in background) immediately upon transaction commit 2 == AUTOMATIC Replication performed asynchronously at a set interval 3 == MANUAL Replication performed synchronously (as a blocking call in the same thread) through direct API calls |
| com.ibm.boca.replication.mode | C: The interval in milliseconds between replication in AUTOMATIC mode S: na E: C | 60000 |
Local model/persistence properties
| property | description | example |
|---|---|---|
| com.ibm.boca.local.immediateEvents.enabled | C: Whether or not to fire Jena Model event listeners immediately upon transaction commit. Otherwise, events will not fire until the triples are committed to the local model and persistent store after replication completes. The desired behavior here is highly application dependent. S: na E: Even though embedded mode has no local persistence, this same decision applies. | false |
| com.ibm.boca.local.persistence.enabled | C: Whether or not to persist the triples of local models in a client-side Derby or db2 database S: na E: na | false |
| com.ibm.boca.client.database.modelName | C: The name of the local database S: na E: na | testModel |
| com.ibm.boca.client.database.clear | C: Whether or not to clear the database on startup, usually for debugging S: na E: na | false |
| com.ibm.boca.client.database.type | C: The type of local database to use S: na E: na | BocaDB2 BocaDerby |
| com.ibm.boca.client.database.fileLocation | C: 'BocaDerby' Location on file system to store the Derby database S: na E: na | /tmp/boca-database |
| com.ibm.boca.client.database.driver | C: 'BocaDB2' The JDBC Driver for RDB local persistence S: na E: na | jdbc:db2://localhost:50000/bocalocal |
| com.ibm.boca.client.database.url | C: 'BocaDB2' The JDBC Url for RDB local persistence S: na E: na | com.ibm.db2.jcc.DB2Driver |
| com.ibm.boca.client.database.user | C: 'BocaDB2' The JDBC username RDB local persistence S: na E: na | db2inst1 |
| com.ibm.boca.client.database.password | C: 'BocaDB2' The JDBC password RDB local persistence S: na E: na | db21nst! |
| com.ibm.boca.client.database.dbName | C: 'BocaDB2' The JDBC database name for RDB local persistence S: na E: na | bocalocal |
Notification client properties
| property | description | example |
|---|---|---|
| com.ibm.boca.notification.notificationClass | C: Notification implementation for DatasetService. S: na E: Defines embedded mode | com.ibm.adtech.boca.services.impl.JMSNotificationService(C) com.ibm.adtech.boca.model.embedded.EmbeddedNotificationService(E) |
| com.ibm.boca.notification.host | C: The location of the JMS Broker to connect to for receiving updates to named graphs S: The location of the JMS Broker to connect to for receiving updates required by internal server components such as the notification service E: C | localhost |
| com.ibm.boca.notification.port | C: The port of the JMS Broker to connect to for receiving updates to named graphs S: The port of the JMS Broker to connect to for receiving updates required by internal server components such as the notification service E: C | 61616 |
| com.ibm.boca.notification.jmsProviderClass | C: The JMS implementation for receiving updates to named graphs S: The JMS implementation for receiving updates required by internal server components such as the notification service E: C | com.ibm.adtech.boca.jms.ActiveMqProvider |
| com.ibm.boca.notification.user | C: The username for connecting to JMS to receive updates to named graphs S: The username for connecting to JMS to receive updates required by internal server components such as the notification service E: C | default |
| com.ibm.boca.notification.password | C: The password for connecting to JMS to receive updates to named graphs S: The password for connecting to JMS to receive updates required by internal server components such as the notification service E: C | 123 |
| com.ibm.boca.notification.enabled | C: Whether or not to connect to a JMS broker to receive updates S: na E: C | true |
Notification service properties
| property | description | example |
|---|---|---|
| com.ibm.boca.repository.notification.broker.enabled | C: na S: Whether or not to start an ActiveMQ JMS Broker in the same JVM as the Web Service E: na | true |
| com.ibm.boca.repository.notification.broker.host | C: na S: The host for the ActiveMQ JMS Broker E: na | localhost |
| com.ibm.boca.repository.notification.broker.port | C: na S: The port for the ActiveMQ JMS Broker E: na | 61616 |
| com.ibm.boca.repository.notification.publisher.host | C: na S: The location of the JMS Broker to which the notification service publishes updates from both the model service transaction handler as well as the multiplexing message queue that broadcasts named graph updates to allowed subscribed users E: The location of the JMS Broker to which the notification service publishes updates from the model service transaction handler. | tcp://localhost |
| com.ibm.boca.repository.notification.publisher.port | C: na S: The port of the JMS Broker to which the notification service publishes updates from both the model service transaction handler as well as the multiplexing message queue that broadcasts named graph updates to allowed subscribed users E: The port of the JMS Broker to which the notification service publishes updates from the model service transaction handler. | 61616 |
| com.ibm.boca.repository.notification.publisher.jmsProviderClass | C: na S: The JMS implementation to use to connect to the JMS Broker from the the model service transaction handler as well as the multiplexing message queue E: The JMS implementation to use to connect to the JMS Broker from the the model service transaction handler | com.ibm.adtech.boca.jms.ActiveMqProvider |
| com.ibm.boca.repository.notification.publisher.user | C: na S: The user to connect to the JMS Broker from the the model service transaction handler as well as the multiplexing message queue E: The user to use to connect to the JMS Broker from the the model service transaction handler | sysadmin |
| com.ibm.boca.repository.notification.publisher.password | C: na S: The password to connect to the JMS Broker from the the model service transaction handler as well as the multiplexing message queue E: The password to use to connect to the JMS Broker from the the model service transaction handler | 123 |
| com.ibm.boca.repository.notification.publisher.enabled | C: na S: Whether or not to publish updates to the JMS cloud. Most Boca servers should enabled this feature. E: Whether or not the backend of the embedded client should publish updates to JMS. This should be enabled when multiple embedded clients will access the same physical database. | 123 |
Boca server properties
| property | description | example |
|---|---|---|
| com.ibm.boca.repository.webserver.host | C: na S: The Web Service hostname/adapter on the server E: na | localhost |
| com.ibm.boca.repository.webserver.port | C: na S: The Web Service port on the server E: na | 8080 |
| com.ibm.boca.repository.webserver.timeout | C: na S: The Web Service timeout on the server E: na | 0 |
| com.ibm.boca.repository.initFile | C: na S: RDF Document to initialize the database with named graphs, users, roles and acls on first startup. Can point to a resource in your classpath. E: S | resource:/com/ibm/adtech/boca/model/initializeNew.nt |
| com.ibm.boca.repository.reset.enabled | C: na S: Whether or not to allow resetting of the database. Should be disabled in deployed production Web Service environments E: S | true |
| com.ibm.boca.repository.reuseConnections | C: na S: Whether or not to reuse JDBC database connections E: S | true |
| com.ibm.boca.repository.cacheStatements | C: na S: Whether or statements are cached in the backend E: S | false |
| com.ibm.boca.repository.authenticationProvider | C: na S: The class to handle authentication of Boca users E: S | com.ibm.adtech.boca.model.security.BocaAuthenticationProvider |
| com.ibm.boca.repository.jmx.enabled | C: na S: Whether or not to enabled Java Management Framework on the Boca server, see BocaAdvancedAdmin E: na | false |
| com.ibm.boca.repository.jmx.port | C: na S: The port that the Java Management Framework listens on, see BocaAdvancedAdmin E: na | 5000 |
Boca database properties
| property | description | example |
|---|---|---|
| com.ibm.boca.repository.database.type | C: na S: The type of backed database E: S | BocaDB2 BocaDerby |
| com.ibm.boca.repository.database.driver | C: na S: The JDBC driver to use to connect to the Boca database instance E: S | com.ibm.db2.jcc.DB2Driver org.apache.derby.jdbc.EmbeddedDriver |
| com.ibm.boca.repository.database.user | C: na S: The user to the Boca database instance E: S | db2inst1 |
| com.ibm.boca.repository.database.password | C: na S: The password to the Boca database instance E: S | db21nst! |
| com.ibm.boca.repository.database.url | C: na S: The url to the Boca database instance E: S | jdbc:db2://localhost:50000/boca jdbc:derby:/tmp/bocaDerby;create=true;upgrade=true |
| com.ibm.boca.repository.database.clear | C: na S: Whether or not to clear the Boca database on startup E: S | false |
Boca DB2 Configuration considerations
In BocaSetup and DB2Setup we showed how to install DB2 and configure Boca to run on it. However, we glossed over a few DB2 configuration detalis that we feel are important to cover now. In particular we had you run a DB2 configure script as black box. Here is the contents of the script.
bind sqllib/bnd/@db2cli.lst grant all CLIPKG 20 create bufferpool BOCABP SIZE 32768 PAGESIZE 4k alter tablespace userspace1 bufferpool BOCABP update db cfg using LOCKLIST 10000 update db cfg using MAXLOCKS 25 update db cfg using LOGFILSIZ 16384 update db cfg using LOGPRIMARY 8 update db cfg using LOGSECOND 4 update db cfg using APPLHEAPSZ 8192 force application all
The important property to modify is LOGFILSIZ. This property, and the following two, specify how much disk space to allocate to transaction log files. This script sets up your Boca database to create 8 primary log files, each of size 16,384x4kb blocks, for a total of 512mb of disk space. If this should fill up, another 4 files for an additional 256mb of logs space are allocated.
