w.r.t to AppServ crash it depends on the current transaction type.

If under the current transaction multiple records are being created or updated then all the EJBObjects will reside in the cache and ejbstore is called only after the transaction completes. Thus the Appserver crash before the transaction completes will not currupt the database.

If the crash occurs during the database update
ejbstore() or after the transaction completes the data is not committed into the database as only after ejbPassivated() the data is commited though the data is lost.

If the Database crashes during the data update then the rollback occurs this ensures that the database is consistent.

Generally, with J2EE unsaved changes are discarted, to enforce transactionality.

If the ejbSvr crashes first, the connection to the db is lost, then the db rolls back the active transactions and the server becomes not reachable, the client should get a RemoteException.

If is the dbSvr to crash first, all the changes are lost and all uncommitted modification too (but this depends from the databases behaviour). Then the AppSvr gets a SQLException and wraps it in a RemoteException to the client.
I assume that uncommitted data are stored in some temporary structure in the db. A bad database could for example corrupt touched data...

In both cases, uncommitted modifications must rationally roll back, even if dbSvr and ejbSvr crash together.

The existence of more or less log files depends on the Application Server that you are using. On WebLogic there's a log to check the jdbc activity too.

If database crashes, we will get SQL Exception
EJB server crashes means never we can store data through Entity Bean(Naming exception will come).