On 27/10/99 11:27:10 A mailing list for Enterprise JavaBeans development
wrote:
>Hey
>
>[EMAIL PROTECTED] wrote:
>> Forgive my ignorance - I'm relatively new to this - but if an Enterprise
>> Bean is forbidden from doing IO or accessing external resources, how is
it
>> possible to implement Bean-Managed Persistence? In this case, the Entity
>> Bean is responsible for storing and restoring its own state in some
>> arbitrary store ( which could be just a file, not necessarily an RDBMS )
-
>> that would be rather difficult without doing IO!
>
>First off, you're not supposed to use files for BMP as they're not
>transactional.
>
Fair enough - just an example.
>That said, it is perfectly possible to implement whatever store you like
>*as long as the core is not packaged with the beans*. Just as JDBC
Does this mean "Just not in the same JAR file". i.e. could you install
BizarreStorageMechanism.JAR in the application server's classpath, and have
it compile-time referenced from a bean ( x = new BizarreStorageMechanism()
)?
Or even runtime-referenced from the bean ( x = Class.forName
( "BizzareStorageMechanism" ).newInstance() )
or would this still count as being packaged with the beans?
>databases may do I/O (duh), whatever you can come up with may use I/O as
>long as you don't package them with your EJB app. NONE of the
>restricitions apply if you do it that way. COMPLETE freedom to do I/O,
>threads, statics, etc. (which also means complete freedom to shoot
>yourself in the foot, but that's your problem...)
So you could, for example, use a third-party O/R mapping library? i.e. by
making calls into it from the ejbLoad and ejbStore methods. Even if this
library was multi-threaded etc. etc. ?
>
>/Rickard
>
>--
>Rickard �berg
>
Cheers
Al
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
