Is it thread-safe?

- Can I call perform CRUD operations from background threads without fear of corrupting the data?

- What would happen if I trigger a CRUD operation from a background thread and abort the background thread while the CRUD operation is on the way - Is there any danger of corrupting the data?

I'm asking because I am currently using a home-brew XML data store which works fine overall, but can be corrupted if the background thread accessing it is interrupted while the XML file is being written.

ORM is, at least to the best of my knowledge, thread safe. If you find an area that's not, let me know because my intent is certainly that is should be. So can you call CRUD operations from worker threads? Yes. We use that
scenario a lot and have had no problems. What would happen if you abort a thread doing a CRUD operation? I don't know - I've not tested it.

I suspect that Thread.Abort is going to tell the scheduler to exit the thread next time it's got a schedule for quantum and if you have an operation that spans multiples, you could have a problem. I suspect that you might get a partial commit (like
if you're updating multiple rows, only some get the update), but you wouldn't get a file corruption. But again, that's only a guess.

It's also not really ORM-specific, that becomes a question of "what's the backing store's behavior in that situation". What happen to a SQLCE command that get's terminated in the same way? Or an XML write? ORM just uses the store's mechanism
for persistance, so it's up to the store's behavior what would happen. Id' say if you have code that is aborting threads that might be storing data, then you might want to look at redesigning - whether you use ORM or not.