We’re using the Camunda engine 7.9.0 with an Oracle database 19c.
In the database, the field “ACT_HI_VARINST.TEXT_” is defined as NVARCHAR2(2000).
Can this field be converted to a CLOB, or does this have any side effects?
@rlehnert You’re encountering the “Value too large for column” error because Camunda 7.9.0 tries to store a variable’s value (typically a String or serialized object) in the ACT_HI_VARINST.TEXT_
column, which is limited to 2000 characters (bytes) in Oracle due to NVARCHAR2(2000)
.
Root Cause:
In Camunda 7.9.0:
- If a variable value is short (<= 2000 characters), it is stored in the
TEXT_
column. - If it exceeds the size, it should be stored in the
BYTEARRAY_
column via theACT_GE_BYTEARRAY
table. - However, Camunda only does this if the variable is declared as a serializable Java object or a byte array, not for long strings.
Recommended Solutions
Option 1: Upgrade Camunda Version
Camunda 7.15+ has much better handling of long string variables. It automatically stores long strings in the ACT_GE_BYTEARRAY
table.
-
Advantage: No DB schema changes required.
-
How:
- Upgrade to at least Camunda 7.15 (7.19 is better).
- Re-test process definitions that store large string variables.
- Optionally, enable the StringValueSerializer fallback mechanism (available in newer versions).
Option 2: Store Large Variables as Serialized Objects
If you cannot upgrade, you can explicitly store long values in a way Camunda uses the BYTEARRAY_
mechanism:
runtimeService.setVariable(processInstanceId,
"longStringVar",
Variables.serializedObjectValue(largeString)
.serializationDataFormat(SerializationDataFormats.JAVA)
.create());
- Pros: Bypasses the
TEXT_
column entirely. - Cons: Stored as a serialized object, not plain text.
Option 3: Manual Workaround Using CLOB (Not Recommended)
You can alter the table to change the column TEXT_
from NVARCHAR2(2000)
to CLOB
, but Camunda does not officially support this, and it may break assumptions in:
- Query performance
- Compatibility with Camunda APIs
- Variable deserialization
If you still want to go ahead:
ALTER TABLE CAMUNDA_PROD.ACT_HI_VARINST MODIFY TEXT_ CLOB;
Side Effects:
CLOB
access requires different handling in Java JDBC (stream-based).- It may break Camunda internal SQL queries that expect
TEXT_
to be NVARCHAR2. - Indexes on this column (if any) will be invalidated.
Best Practice (Short-Term Fix)
If upgrade isn’t possible yet:
-
Avoid setting long strings as process variables directly.
-
Instead:
- Store large data in external storage (e.g., DB or S3).
- Pass a reference (ID or URL) as a short string variable.
Hello,
Are you Upgrade to at least Camunda 7.15 ?
Best Regard,
Angela
@aravindhrs,
thank you for the detailed explanation.
I will discuss a migration to 7.19 with my colleagues in IT.
This seems to be the most sensible approach.
Best regards
Rolf
This is not true IMO. Strings are still saved as strings. Hence, if you have a string value that is longer than 2000 characters you should store it in a wrapper object. Objects are always stored as blobs so there is no limitation on the size.
Camanda 7.9 is ancient. Why do you still use this version (asking just out of interest).