Don't worry too much.
Apache Derby is IBM (ex Sybase) Cloudscape donated to the open source community and rebadged.
If you use stand alone processes, only one process can access Cloudscape/Derby databases - as you know.
But IBM also provided a server that would allow multiple connections, and provided the same functionality within connection pools in an application server.
So you should write your entity layer to persist to the database through pooled connections to the Derby/Cloudscape database. Assume that the connection pool and underlying software will handle multiple connections.
This still leaves you with the normal problems.
You may need, or want, to use Bean Managed Persistence because your objects don't look like rows in a relational database (mine never do).
And you need to make sure that, when dealing with updates on multiple tables, you always update tables in the same order to avoid deadlocks.
But at least you don't need a special pattern.
Yes, there is Derby version as a network server - I managed to run it succesfully. Now I will try to use it from JBoss via JDO.
As for database - yes the objects should not be like rows in db tables when system is designed correctly (hm by my ones often are).
Anyway with JDO i will not be very focused how db tables look like.
And as a matter of fact, I even don't know really why do we need entity beans when we have JDO. I plan to develop only session beans.
One way to get that embedded "feel" (that is, your database starts and stops along with your app server) while still providing a network server is to follow this example from IBM (the enterprise integration one):
The examples are based on an old version though, so code changes are necessary. Probably not the best way to bring the database up/down with JBoss, but it does the job.