About File Checkins

The FCS supports two types of checkin: one-part checkin is employed when the business object the file is checked into does not exist yet, and two-part checkin is used when the business object already exists. FCS allows override triggers, but only when FCS is disabled during the override trigger operation.

Checking in a set of files to the FCS involves four steps:


  1. Creating a ticket corresponding to the number of files.
  2. Using the ticket, uploading the files into the FCS, and receiving a receipt.
  3. Creating the object proxies that materialize the association between a Business Object and a file previously uploaded.
  4. Validating the check in operation using the receipt and the list of proxies.

Any Java client application that will perform FCS checkin or checkout operations, must now explicitly reference the FcsClient.jar instead of the eMatrixServletRMI.jar. The following error will occur if the Java client is not referencing the FcsClient.jar: <java.lang.NoClassDefFoundError: com/matrixone/client/fcs/InputStreamSource_2>

Before a checkin/checkout operation to/from a store or location, verify that the FCS server defined in the FCS_URL on that store or location is running. If not, the operation will fail. Additionally, you should verify factors that may also affect the operation, like a LAN line being down.

If several users try to check in files simultaneously, some of the checkins may fail with an FCS error. This can be avoided by increasing the thread pool size of the application server. The following table provides information on adjusting thread pool size in various application servers.

Application Server Adjusting Thread Pool Size
WebSphere See http://publib.boulder.ibm.com/infocenter/wasinfo/v5r1//index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/uejb_rthrd.html.
WebLogic Tune the pool size by providing pool sizes (such as pools for JDBC connections, Stateless Session EJBs, and MDBs) that maximize concurrency for the expected thread utilization.
  • For WebLogic Server v9.0 and higher—A server instance uses a self-tuned thread pool. The best way to determine the appropriate pool size is to monitor the pool's current size, shrink counts, grow counts, and wait counts. See "Thread Management." Tuning MDBs are a special case. See "Tuning Message-Driven Beans."
  • For earlier releases—In general, the number of connections should equal the number of threads that are expected to be required to process the requests handled by the pool. The most effective way to ensure that the pool size is right is to monitor it and make sure that it does not shrink and grow. See "How to Enable the WebLogic 8.1 Thread Pool Model."
Sun Java System Application Server See http://docs.sun.com/app/docs/doc/819-3681/abefm?l=En&a=view.
Tomcat See http://tomcat.apache.org/tomcat-6.0-doc/config/executor.html.