Use SolrJ to send Java documents to Solr: create a SolrInputDocument, populate it, and call a SolrClient add method. With a schema unique key, adding a document whose key already exists replaces the stored document by default. For field-level changes, use atomic updates; for concurrent writers, include the expected _version_. A successful write does not by itself guarantee immediate search visibility—choose a commit strategy that fits your freshness and durability needs.
Set up SolrJ and choose a client
SolrJ is Apache Solr’s Java/JVM client API. The Apache Solr Reference Guide for Solr 10.0 documents the Maven dependency as org.apache.solr:solr-solrj:10.0.0. Match the client version to the Solr release deployed in your environment; the example below follows the Solr 10.0 guide and is not a compatibility guarantee for other releases. Apache Solr Reference Guide: SolrJ.
A SolrClient sends update requests. The Solr 10.0 guide lists CloudSolrClient for SolrCloud routing, ConcurrentUpdateJettySolrClient for indexing-oriented workloads with internal buffering, and HTTP clients for direct HTTP communication. Select the client appropriate to the deployment and workload, and consult the guide for release-specific details.
Add or replace a complete document
Construct a SolrInputDocument, set fields that match the collection’s schema, then submit it to the collection. This SolrJ example illustrates the basic operation:
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →SolrInputDocument doc = new SolrInputDocument();
doc.addField("id", "book-123");
doc.addField("title", "A Solr example");
doc.addField("author", "A. Writer");
UpdateResponse response = client.add("catalog", doc);
// Apply the deployment's chosen commit/visibility strategy.The example assumes an id field that is the collection’s unique key and a client that has already been configured. Field names and value types must correspond to the collection schema. SolrJ can also map annotated Java beans using @Field and client.addBean(collection, bean); bean mappings do not remove the need for the schema to agree with the fields being indexed. The guide’s short example commits after adding, but explicitly says it is for syntax and breaks best practices: normal applications should batch documents, and administrators should generally configure auto-commit instead of having clients commit after each document. SolrJ indexing example and guidance.
What an add does when the key already exists
Under the default overwrite behavior, adding a document with a matching schema unique key replaces the prior version. This is commonly how a full-document update is performed: submit the new complete document with the same key. Avoid overwrite=false unless the ingestion design guarantees that duplicate keys cannot occur, because disabling the check can permit duplicate documents. Apache Solr Reference Guide: Indexing with Update Handlers.
Rank #2
Change selected fields with atomic updates
When only some fields need to change, an atomic update sends field modifiers instead of a complete replacement document. Supported modifiers include set, add, remove, add-distinct, and numeric inc operations (including decrements expressed as a negative increment). For example, a request can set a new price while incrementing popularity, leaving other fields logically unchanged. The exact field types and update form must be valid for the collection schema. Apache Solr Reference Guide: Partial Document Updates.
Do not assume every atomic update touches only the changed field internally. A regular atomic update reindexes the entire document. Solr has a narrower in-place update path for eligible fields, but it requires strict schema conditions: the field must be single-valued numeric docValues, not indexed and not stored; _version_ and any copy-field targets must also satisfy the documented constraints. Treat in-place updates as a schema-specific optimization, not the default behavior for every partial update. In-place update requirements.
Recommended Free Tools
Protect edits from concurrent writers
If another writer may change a document between your read and write, use optimistic concurrency so your update is conditional on the version you read. Solr adds the reserved _version_ field to documents under the default schema. Do not repurpose it: Solr uses it for versioning and SolrCloud update distribution. Optimistic concurrency and versioning.
- Read the current document and its
_version_, using the RealTime Get API (often called/get) where appropriate. - Apply the desired local change without discarding fields that must be retained.
- Submit the update with the expected version so Solr can check that the document has not changed since the read.
- If Solr returns HTTP 409 for a version conflict, reread the current document and decide whether to merge and retry or report the conflict to the caller.
For batched updates, one version conflict can reject the whole batch. The update guide documents failOnVersionConflicts=false for cases where individual conflicts should be skipped instead. Choose that behavior only if the application can safely tolerate some updates in the batch not being applied. Conflict handling.
Rank #4
Delete by ID or query
Solr update handlers support deletion by unique ID and by query. Deleting by ID relies on the schema’s unique key; deleting by query removes documents matching the supplied query. Some query parsers impose restrictions on delete-by-query, and commitWithin is ignored for delete-by-query. SolrJ exposes client delete operations, and request objects can be used to call other Solr APIs. Update handler delete operations; Apache Solr Reference Guide: Client APIs.
Choose when writes become searchable
Submitting an update and seeing it in search results are separate events. Solr commits determine when additions and deletions become visible to searchers. A hard commit flushes data to stable storage; a soft commit makes updates visible to search without waiting for the same storage and background-merge work. Auto-commit can be configured by document count, elapsed time, or transaction-log size, while auto-soft-commit sets a search-visibility cadence. commitWithin is another update-level option. Shorter visibility delays may reduce freshness lag but can cost performance, so select settings for the application’s latency and durability requirements rather than copying a sample interval. Apache Solr Reference Guide: Commits and Transaction Logs.
Best Value
The SolrJ indexing example says, “Indexed documents must be committed,” but its immediate client commit is not a recommendation to commit each individual document. The same guide favors batching and configured auto-commit for ordinary applications. Its example values of a 60-second hard commit and a 10-second soft commit are examples, not Solr defaults. SolrJ; Commit configuration.
Quick Recap
Choose the update approach that fits
| Need | Approach | Important behavior |
|---|---|---|
| Replace the complete document | Add a complete document with the same unique key | Default overwrite behavior replaces the existing document. |
| Change selected fields | Atomic update | Regular atomic updates reindex the whole document internally; in-place processing is limited to qualifying schema fields. |
| Avoid overwriting a concurrent edit | Optimistic concurrency with expected _version_ |
A mismatch returns HTTP 409; reread and resolve or retry according to application policy. |
| Control write visibility and durability timing | Configured hard/soft auto-commit or update-level commitWithin |
Hard and soft commits serve different purposes; shorter visibility intervals can affect performance. |
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
