While it is possible to access a database directly from within Silverlight 4, it requires out-of-browser installation and elevated trust. Since you didn't mention this scenario, I'm assuming your application is using Silverlight as most applications do,
as a front-end for a client-server environment.
If that's the case, it's quite easy to have the Silverlight client access a webservice that runs on a server that can access the database and wrap its database calls in a transaction. Even if you have multiple service methods that need to be called, it's
typical to create a service endpoint with the exact granularity of the unit of work, which service itself can make calls to other methods, internally, that are wrapped with a transaction.
The Silverlight client doesn't need to know anything about the transaction actually taking place, except to know whether the method succeeded or not. This technique works for the majority of transaction needs.
Furthermore, with WCF RIA Services and Entity Framework, the data context passed between the Silverlight client and the WCF service will automatically save changes to related records using a transaction; thus, changes can be made to the data on the client,
and a single method call on the client will automatically persist the changes and take care of all communications and transactions along the way, all the way to the database. As a bonus you get client- and server-side validation using automatic client code
generation, as well as automatic WCF service configuration and proxy generation.
