> > Be careful with this solution. It's not as easy as
> is
> > said. I had a lot of problems with it. If you are
> > going to do batch processing with EJB timers, you
> > have to be very careful. EJB timer allows you to
> call
> > EJB stateless and statefull session beans and they
> > does not allow you to access files. Most of the
> time
> > patch processing is dealing with files.
>
> I call shenanigans.
>
> Yes, the JEE spec considers file access by an EJB to
> be "unsupported" in terms of the spec. However, I
> don't know of a single container that actually
> enforces this restriction. The motivation behind it
> is that EJB is a distributed component framework, and
> in that light the intent is that EJBs can be deployed
> "anywhere", particularly in a clustered environment.
> In these cases, relying on the filesystem means
> you're relying on a "resource" that is not managed by
> the container. If it's not managed by the container,
> it's not "portable". If you want to be pure to spec,
> write a JCA resource to represent your file system.
>
> But the reality is simply that most developers can
> actually work around the details of "knowing" where a
> component is deployed (perhaps it's not a clustered
> system, perhaps it's a configuration variable
> specifying a correct location, perhaps it's a network
> filesystem mapped to the path on every node).
>
> Bottom line, files work fine in EJB. It's just not,
> per spec, "portable".
>
Thanks, you said exactly what I meant. The reason I said that and stand firm on my words, that person before going to do something have to know all issues what he will face.
I don't understand this kind of attitude, this is like having suggestion from enemy. Go to that direction, if you will face any problem then, fuck off, you haven't asked about that, and if you will have to use JCA or anything else just to get access to files that's fine this is a life.
This attitude is very destructive, person can receives following experience:
1. that suggestions from forum can be very bad and it's better not to trust them.
2. Glassfish and Java EE is a devil's tools. It's better not to touch them at all, because you never know what next problem will come.
3. people what suggesting solutions care less about the person's problem, they more concerned about technology, not about me.
> > Another issue, if you are going to move big
> amounts
> > of data between files or different databases you
> will
> > have long transaction. All data in that
> transaction
> > will be collected in memory and released only
> after
> > completion. You have to know amount of data and
> how
> > much memory will be consumed during this process.
>
> More shenanigans. Regarding databases specifically, I
> don't know of a single modern database who has
> transactions that are memory bound. Typical databases
> will have transactions log bound, assuming fixed log
> sizes configured for the database. There's no reason
> for a database to hold pending transactions in
> memory. It's insane, it has to write the data
> anyway.
>
> Should you be concerned how much memory your
> processes take? Of course, but the database won't be
> your smoking gun and neither will the EJB transaction
> subsystem. It doesn't "remember" anything either.
>
> Most problems with long running transactions in EJB
> systems revolve around network connection timeouts
> from clients. EJB Timers don't suffer that problem
> since they're local to the container (unless they
> themselves are network clients, for example calling a
> long running remote EJB session bean).
>
Problem is related not with db, but default JPA implementation for glassfish. Toplink essentials is one to blame for huge memory consumption. Of-course it's possible to change to another implementation like Open JPA or Hibernate, but still it's better to warn person what kind of problems he will have to deal with.
> > Development of batch processing tasks on glassfish
> > was problematic and I got a lot of headache and
> > sleepless nights, but at the end it works very
> well
> > and I'm happy how stable and reliable it's.
>
> I'm glad he's happy with his Spring solution, but I'm
> very interested in more specifics about what his
> issues were.
I'm not happy with Spring-batch. I'm even don't use it. But I know it could be better solution. When I started to do batch processing job on Java EE with Glassfish, nobody warned me and nobody advised for best possible solution.
My point is, please give best possible solution you can, don't use you loved technology for everything. Be honest by helping to person, not to technology.
[Message sent by forum member 'remisb' (remisb)]
http://forums.java.net/jive/thread.jspa?messageID=287238