Hi,
I can't tell all the parameters of your situation. If you are updating
individual rows of the database one by one, you should use commit option B
or C. These are adapted for non exclusive access to the db by the ejbs. I
think Daniel's solution is for when you are doing a batch update and want
to use commit option A for speed and then reload all the beans at once.
Hope this is relevant
david jencks
On 2001.04.26 14:39:18 -0400 [EMAIL PROTECTED] wrote:
> Hi Daniel:
>
> Thank you for the quick response. I currently have a jBoss based product
> supporting 50 internal customer service reps. The beans report on things
> like balances and such, and they need to be up to date. The cache
> manager
> you are talking about, is it a customer manager you wrote, or one
> integral
> to jBoss? I need to work something out until I can get my external
> processes to use SOAP :) which I'm off to SOAP land now...
>
> Wes
>
> BTW: We need to write a SOAP RPC compiler which takes a EJB remote
> interface and compiles the client automatically, like rmic. If anyone
> knows
> of such a compiler, let me know.
>
> BTWW: I have written an ant task to which automatically rebuilds
> jboss.xml
> and ejb-jar.xml so the whole project can be built and deployed from ant.
> If
> anyone is interested, let me know and I will send the source code and a
> sample to the proper place. It isn't complete, but it is nice rebuilding
> entire JAR/WAR files from scratch with one command.
>
> -----Original Message-----
> From: Daniel Cardin [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, April 26, 2001 2:08 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-user] External Data Modification
>
>
> Hi Wes :)
>
> There is a thread that we started not too long ago on the topic. The way
> we have handled it is by creating our own instance of a cache manager
> for JBoss that is able to mark beans as dirty (thus are reloaded through
> ejbLoad on the next call). We have JMS setup so that our "traditionnal"
> application posts messages to the cache manager when making changes.
>
> A similar approach could be taken using triggers in the tables concerned
> I think... As long as your database allows you to call on external
> functions in triggers (as MS SQL does).
>
> Feel free to ask more questions if you aren't sure what the heck I'm
> talking about :)
>
> HTH,
>
> Daniel
>
>
> -----Message d'origine-----
> De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Envoy� : 26 avril, 2001 14:03
> � : [EMAIL PROTECTED]
> Objet : [JBoss-user] External Data Modification
>
>
> I know I've seen some discussion of this in the past, but it never
> affected
> me until today, and I am having no luck searching the archives. I
> would
> like to know the best way to handle non-EJB modifications to the
> underlying
> data of an Entity Bean. The bean is not reloaded until it is over aged.
> I
> would apprecate hearing from anyone else who has encountered this
> problem.
>
> Wes
>
>
> _______________________________________________
> JBoss-user mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-user
>
> _______________________________________________
> JBoss-user mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-user
>
> _______________________________________________
> JBoss-user mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-user
>
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
