Remove many records
Hi.
In SQL i can do like this "DELETE FROM customers WHERE id>100"
And there'll be only one call.
But if i use ejb, i should do next steps:
Collection coll = myHome.findByMoreId(long id);
Iterator iter = coll.iterator();
while(iter.hasNext) {
((MyBean)iter.next()).remove();
}
There'll be a huge of calls. I can make such operation working under Session+JDBC. But in this case i have to set up my application server in non-dedicated mode. And it'll be slowly too.
What have you been doing in such cases?
Thank's
[598 byte] By [
darkit] at [2007-9-19]
Greetings,
> There'll be a huge of calls. I can make such operation
> working under Session+JDBC. But in this case i have to
> set up my application server in non-dedicated mode.
> And it'll be slowly too.
What do you mean by setting your "server in non-dedicated mode"? In any case...
> What have you been doing in such cases?
Using a Session Bean to make the JDBC calls. However, in 2.0 there a now a couple of other possibilities: use a Session Facade to iterate through the EBs using their Local interfaces; or, use a Home method on your EB. Perhaps your vendor has an update compliant with EJB 2.0...
> Thank's
Regards,
Tony "Vee Schade" Cook
I just want to add one point.If you use JDBC calls to delete, you can't have customer as Entity bean. If you have Customer EB and use JDBC call to delete, it will not be reflected in EB.
Greetings,
> I just want to add one point.
>
> If you use JDBC calls to delete, you can't have
> customer as Entity bean. If you have Customer EB and
> use JDBC call to delete, it will not be reflected in
> EB.
One could make that same point about deleting any type of record from behind an Entity Bean! However, deleting a record from behind an EB will reflect in the EB the next time it hits the resource. That's what ObjectNotFoundException and, especially, NoSuchEntityException are for. A well designed - and coded - app will handle, and reflect, such behaviour just fine.
Regards,
Tony "Vee Schade" Cook
Non-dedicaded means that server knows he's working with database and nobody else.
I use iAS(aka Orion). And if you delete record through jdbc, server won't know about it nothing. And it'll return deleted bean to you.Using local interfaces doesn't solve the problem, it'll be fast to get bean, but there'll have been many calls to DB still.
Use session bean to delete it
Greetings,
> Non-dedicaded means that server knows he's working
> with database and nobody else.
> I use iAS(aka Orion). And if you delete record through
Sounds like a vendor specific setting. It is generally not a good idea to code to a specific vendor if portability is at all a concern...
> jdbc, server won't know about it nothing. And it'll
> return deleted bean to you.Using local interfaces
So, in "dedicated" mode the bean rarely syncs with the resource. That's certainly a speed improvement - though, also a risky one (what happens if the server crashes?) - but, again, not very portable if your application relies on the behaviour.
> doesn't solve the problem, it'll be fast to get bean,
> but there'll have been many calls to DB still.
Yes, however, the (rather large) overhead of the remote calls - being much more than just "getting the bean faster" - is eliminated. Hitting the database is less of a concern where connection pooling is used (even complex queries/statements execute in "no-time" compared to establishing a connection). In any case, it seems that if you put your server in "dedicated" mode using Local interfaces is an acceptable solution.
Regards,
Tony "Vee Schade" Cook
>Sounds like a vendor specific setting. It is generally not a good idea to code to a specific vendor if
>portability is at all a concern...
It's vendor specific for server configuration to increase speed. My code'll work everywhere, because i use only pure j2ee libraries.
It's not my problemm if server crashes, isn't it?If your hard drive crashes nothing'll save you except RAID :)))
But iAS(Orion) doesn't support Local Interfaces :((
And my question was about ejb techonolgy. it's seems like ejbeans aren't for real life.
If i use JDBC why i should mix techonolgies. I can do everything with jdbc. EJB is for easing of life.
I've just wanted to use only EJB. But I should use jdbc for large select and delete, and EJB for insert and update.
> >Sounds like a vendor specific setting. It is
> generally not a good idea to code to a specific vendor
> if
> >portability is at all a concern...
> It's vendor specific for server configuration to
> increase speed. My code'll work everywhere, because i
> use only pure j2ee libraries.
Good, however, I was making reference to coding against server behaviour. If the application doesn't properly respond to the possibility of data being modified or deleted from behind the bean (which is a very real likelihood in "real world" enterprise settings), because it (the client-side, at least) is written in reliance upon a server's "dedicated" mode behavior, then portability suffers, regardless of how "pure" the J2EE libraries. :)
> It's not my problemm if server crashes, isn't it?If
That's one way of looking at it. However, if after restart the deployer/customer's data is not in a consistent state (because the server, in "dedicated" mode, failed to sync back to the resource sufficiently before the crash...), guess who is most likely to receive the repercussions (and blaming the platform in retort would only hurt the credibility of the J2EE platform which all J2EE developers - IMHO - have a responsibility to uphold - that is, unless you're ready to move to .Net :-p )...
> your hard drive crashes nothing'll save you except RAID :)))
Unless, of course, the crash is controller related. :) Then nothing'll save you except backups... (ad naseum, ad infinitum....) :-p However, I'm talking about non-disk related crashes (memory errors, scalability limits, security holes, server bugs ':-o , etc.).
> But iAS(Orion) doesn't support Local Interfaces :((
Last time I checked, Orion has little, if any, J2EE 1.3/EJB 2.0 support. Maybe I'll check again... nah! I'll stick with JBoss. :)
> And my question was about ejb techonolgy. it's seems
> like ejbeans aren't for real life.
Well, Sun, at least (not to mention 70% - re: Gartner - of the app-server industry), thinks they are...
> If i use JDBC why i should mix techonolgies. I can do
> everything with jdbc. EJB is for easing of life.
Er, EJB (and J2EE/middleware in general) is for facilitating business process - taking advantage of supplied - commonly needed - enterprise services (security, transaction management, persistence, etc.), allowing developers to focus on the rules of the business. Entity Beans, in particular, are for providing OO views to shareable, cacheable, persistent data. For such data - particularly that which is frequently accessed - 'JDBC direct' represents a significant bottleneck, which EBs are designed to alleviate.
> I've just wanted to use only EJB. But I should use
Not a realistic goal in "real world" enterprise environments, where EJBs must often collaborate with legacy infrastructures and prior history applications. However, if the enterprise is just starting up then it's a feasible goal, but a solid design should be in place first (80/20 rule).
> jdbc for large select and delete, and EJB for insert
> and update.
It's a matter of design which is still largely an art.
Regards,
Tony "Vee Schade" Cook
I mean Entity Beans. Session and M beans are cool :) But it's easy for me, create session bean which will analogue of entity beans, but it can return huge data and delete them and working with JDBC. If yout entity bean syncs every operation with db it's very slowly.
EJB:
select: findByMoreId() -> find -> sync -> return Collection
update: findByMoreId() -> find->sync->return Collection -> while(...) ((MyBean)iter).setSomeThing() -> sync
delete: findByMoreId() -> find -> sync-> return Collection-> while(...) ((MyBean)iter).remove() -> sync
insert: create() -> sync
JDBC:
select: selectByMoreId() -> db select -> return Collection
update: updateMoreId() -> db update
delete: deleteMoreId() -> db delete
insert: insert() -> db insert
So where is a bottleneck?
Greetings,
> and delete them and working with JDBC. If yout entity
> bean syncs every operation with db it's very slowly.
Aaah, I think you misunderstand the lifecycle of Entity Beans. In accordance with their cacheable natures, Entity Beans do not (necessarily) sync with every operation. They sync on create and remove as should be rightly expected. They sync sometime after business methods, though when exactly is up to the discretion of the container. This, however, is largely influenced by the transaction model in effect. IOW: if every business method runs within its own transaction context then sync will likely occur after every method call - though, with BMP, whether the resource is actually hit can be controlled with a 'dirty flag' - so, transaction models should be decided thoughtfully. However, when exactly, again, it happens is at the container's (vendor's) discretion and "smart" container's initiate a sync after the last concurrent transaction. (I think I'm beginning to see why the Orion developers created a "dedicated" mode - perhaps they couldn't figure out how to effectively manage concurrent transactions? :) That is a reflection of an EB's shareable nature! Finally, swapping also incurs a sync though when, or if, swapping occurs is influenced by the server's resources (EJB's - and middleware - afterall, are about Enterprise applications and are targeted at "large" server environments ;).
> EJB:
> select: findByMoreId() -> find -> sync -> return
> Collection
> update: findByMoreId() -> find->sync->return
No. Finders do not incur a sync operation. In fact, if the finder method must actually be invoked, it is invoked on an instance (while it is) in the pool! A finder's only purpose is to locate Entity Beans - and, consequently, entities - and return their keys. This, of course, involves hitting the resource but only when the looked for EB(EJBObject)/entity is not already in the container space (though, with multi-key finders this will depend on how smart is the vendor's implementation).
> Collection -> while(...) ((MyBean)iter).setSomeThing()
> -> sync
> delete: findByMoreId() -> find -> sync-> return
> Collection-> while(...) ((MyBean)iter).remove() ->
> sync
> insert: create() -> sync
Refer again to the above. :)
> JDBC:
> select: selectByMoreId() -> db select -> return
> Collection
> update: updateMoreId() -> db update
> delete: deleteMoreId() -> db delete
> insert: insert() -> db insert
These actually do hit the resource on every operation...
> So where is a bottleneck?
In the fact that JDBC does hit the resource with every operation. The database must (typically) work with the slowest part of a system - disk I/O - and probably while doing so within a transaction context. Multiple clients acting on the same entity reflect this rather quickly, especially since each client's operation is acting directly on the database! Compare that to the fact that an Entity Bean provides shared, concurrent, access to the entity and the bottleneck in 'JDBC direct' should become obvious.
Regards,
Tony "Vee Schade" Cook
Thank you, pendraco.You've really helped me.
