span8
span4
span8
span4
Apersistent connectionallows database connections to remains open for other requestors.A persistent connection is useful for workspaces that are long-running or published using FME Server.If this parameter is not selected,the connection to the Oracle database is closed as soon as possible after data processing is complete.
On FME Desktop,a persistent connection leaves the Oracle connection open until each translation finishes or in the case of FME Server,until an engine restart.By default the engine restart is set to 100 successful or 10 failed jobs,but this can be modified by setting theMAX_TRANSACTION_RESULT_SUCCESSESparameter in the configuration.
Persistent connections are the default setting for the readers,writers,and transformers.
For a persistent connection (default),the connection will remain until the workspace translation ends or in the case of FME Server,until an engine restart.Additionally,the TCP connections by nature will hold on to any port for another 2-4 minutes after Oracle and FME have closed the connections.
A non-persistent connection is closed as soon as possible after data processing is complete.
Oracle writers will create their own second connection,while Readers and Transformers will share the first connection (if all transformers and reader/writers are set to persistent connections).
FeatureReaders / FeatureWriters use the same connections methods as readers and writers.So for purposes of persistent connections,they should be treated the same as regular readers and writers.
Child processes sent by the FME desktop from a workspaceRunner are new instances,so unlike FME Server,the child process will use new connections and not the parent's persistent connections.
Child jobs sent from FMEServerJobSubmitter will use the same instance of the engine as their parent and therefore use the parent's persistent connections.
Occasionally when there are timeouts for idle connections,a long-running query executed in a transformer downstream can cause the connection to become idle.If the reader shares a connection with the transformer it may fail due to a database or firewall timeout.In such a case you can have the reader read everything and cache it in memory with aFeatureHolderbefore the transformer starts executing.
The key point states "Readers will not cause a failure if everything is read,but the workspace is still processing." – So from that can I infer that the Reader will close its connection once it has finished reading?So if a reader reads everything,and a Firewall timeout terminates the Readers connection while the ETL is processing and writing,the ETL will be successful when it finishes and will not fail when it finishes because it cannot "close or sign off" the reader connection ?
Yes,that is correct if the reader has read all the data,but the workspace is still processing the data and you have no other connections using the reader connection,the workspace will continue along and while you may see Warnings it should not fail.If you find otherwise please feel free to create a case.
Let the Database Do the Work: Reading
Performing spatial queries on database tables using the FeatureReader
Connection to Oracle Database Fails to Close After Translation Completes
How do you connect to an Oracle Database with OS authentication (Windows)
Writing custom data types to an Oracle table
Writing to Database Tables that contain Multiple Geometry Columns
Updating SRID values in an Oracle geometry column
Oracle Writer may reach maximum vertices in a feature.
© 2019 亚搏在线Safe Software Inc |Legal