As you can see PaperCut has many areas where it will momentarily use a database to either read, update or store new information.
Obviously we have gone to lengths to make sure we’re as efficient as caffinely possible. We make use of Connection Pooling and Connection Reuse algorithms. For example, one connection might be used to update a users balance because they’ve just printed a document, then a few milliseconds later we need to check the email address of another user, we’ll re-use that connection rather than close and reopen one. Once a connection has become idle for a while (configurable) we’ll close the connection.
This means that the total number of database connections can not be directly correlated to the number of print jobs, user sessions or copiers, etc as not all of these processes happen at the same time.
Under normal operating conditions the number of database connections will remain consistently low. The number will increase to meet demand and reduce down afterwards. This can lead to spikes in the number of connections during busy moments, for example a remote office’s internet connection has started working again or a large batch of print jobs is released.
Please note: Unexpected behaviour can occur if a database has been configured to restrict the number of connections that PaperCut can make to an external DBMS. For sites dealing with high print volumes and many users, this number may need to be as high as 400 simultaneous connections.
This release contains an updated Java version which no longer supports 32-bit workstations. If you have any 32-bit users launching the User Client or Release Station from a network share, see this Knowledge Base article for more information.